DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
This is in response to an amendment/response/communication filed 6/17/2026.
Claim 7 and 20 has/have been cancelled.
Claim 22 have been added.
Claims(s) 1-6, 8-19 and 21-22 is/are currently pending.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 6/17/2026 has been entered.
Response to Arguments
Applicant’s arguments, see pages 8-10, filed 6/17/2026, with respect to the rejection(s) of claim(s) 1-6 and 8-20 under 35 U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Zhu et al., “Packet-Level Telemetry in Large Datacenter Networks”, August 17-21, 2015, SIGCOMM ’15, pp. 479-491 in view of Liu et al. US 20230112928 (cited in Non-Final Rejection dated 1/28/2026) and in further view of Shevach et al. US 20170034003.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 3, 4, 5, 8, 10, 11, 12, 14, 15, 17 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al., “Packet-Level Telemetry in Large Datacenter Networks”, August 17-21, 2015, SIGCOMM ’15, pp. 479-491 in view of Liu et al. US 20230112928 (cited in Non-Final Rejection dated 1/28/2026) and in further view of Shevach et al. US 20170034003 (cited in Non-Final Rejection dated 1/28/2026).
As to claim 1:
Zhu et al. discloses:
A system comprising:
a processor; and
a computer-readable medium storing instructions that are operative upon execution by the processor to:
collect topology data for a packet-switched network;
(“Latency profiler. Many DCN services, e.g., search and distributed memory cache, require low latency. To find out why the latency between any pair of servers is too high, the latency profiler will first mark the debug bit of the TCP
SYN packets between the two servers. From the traces of these packets, it knows the network devices on the path and then launches guided probes to measure the per-hop latency. Guided probing measures the roundtrip latency of each link instead of the one-way latency. This degree of localization suffices in practice. With this localization information, the profiler can quickly identify the network devices that cause the problem”; Zhu et al.; p.484, right col., middle of page)
(“For each complete packet trace, the analyzer checks for two types of problems: loop and drop. A loop exhibits as the same device appearing multiple times in the trace. A drop is detected when the last hop of the trace is different
from the expected last hop(s) which can be computed using the DCN topology and routing policy. For example, the expected last hop of a packet destined to an internal IP address of the DCN is the ToR switch directly connected to the IP
address. The expected last hops of a packet destined to an external IP address are the border switches of the DCN.”; Zhu et al.; pl 483, right col., middle of page)
(“We present Everflow, a network telemetry systemthat provides
scalable and flexible access to packet-level information in large DCNs. To consistently trace individual packets across the network, Everflow uses “match and mirror." Commodity switches can apply actions on packets that match on
flexible patterns over packet headers or payloads; we use this functionality with mirroring packets to our analysis servers as the action. By installing a small number of well-chosen match-and-mirror rules means we can reap the benefits of packet-level tracing while cutting down the overhead by several orders of magnitude.”; Zhu et al.; p.480, left col., top of page)
(where
“From the traces of these packets, it knows the network devices on the path”/”using the DCN topology”/”switches can apply actions on packets”/Figure 4/Figure 7a/Figure 10b maps to “collect topology data for a packet-switched network”, “knows the network devices on the path” maps to “collect topology data”, “switches…packets” maps to “packet-switched network”, where Figures 4, 7a and 10b illustrate “network”
build a network topology of network nodes of the packet-switched network, using the topology data;
(“We now present the trace collection and analysis pipeline of Everflow. As shown in Fig 4, it consists of four key components: the controller, analyzer, storage and reshuffler. On top of that, there are a variety of applications that use the packet-level information provided by Everflow to debug network faults. The controller coordinates the other components and interacts with the applications. During initialization, it configures the rules on switches. Packets that match these rules will be mirrored to the reshufflers and the directed to the analyzers which output the analysis results into storage. The controller also provides APIs which allow Everflow applications to query analysis results, customize counters on the analyzers, inject guided probes, and mark the debug bit on hosts. We describe the analyzer and controller in this section and the reshuffler and storage in §6.”; Zhu et al.; p.483, left col., bottom of page)
“From the traces of these packets, it knows the network devices on the path”/”using the DCN topology”/”switches can apply actions on packets”/Figure 4/Figure 7a/Figure 10b/”switches” maps to “build a network topology of network nodes of the packet-switched network, using the topology data”, where “switches” maps to “network nodes”
tag a first set of tracing packets with a tag;
(“To support such flexible tracing, we allow the packets to be marked by a special “debug” bit in the header. The marking criteria can be defined in any manner, as long as the total tracing overhead stays below a threshold. In the switches, we install a rule to trace any packet with the “debug” bit set”; Zhu et al.; p.481, right col., bottom of page)
(where
“allow the packets to be marked by a special “debug” bit in the header. The marking criteria can be defined in any manner, as long as the total tracing overhead stays below a threshold. In the switches, we install a rule to trace any packet with the “debug” bit set” maps to “tag a first set of tracing packets with a tag”, “marked” maps to “tag a”, “packets…trace” maps to “first set of tracing packets”, ““debug” bit” maps to “with a tag”
execute, by packet trace workers, a capture state machine;
(“When a packet matches any rule, the switch will mirror it and encapsulate the mirrored packet using GRE (Generic Routing Encapsulation). Fig. 6 shows the format of the GRE packet, where the source IP is the switch loopback IP, the destination IP is the VIP of the reshufflers, and the payload
is the original packet (starting from the L2 header). Inside the GRE header, there is a protocol field which is used to indicate that this is an Everflow mirrored packet. We configure every switch with a blacklist rule to prevent mirroring a mirrored packet.”; Zhu et al.; p.485, right col., middle of page)
(“Finally, our tracing coverage goes beyond data packets. A DCN has a small amount of traffic associated with network protocols such as BGP, PFC, and RDMA.We call it protocol traffic to distinguish from regular data traffic. Although the absolute volume of the protocol traffic is small, it is critical for the overallDCN health and performance. Thus, Everflow has rules to trace all the protocol traffic.”; Zhu et al.; p.482, left col., middle of page)
(“Match and mirror on switch…First…Second…”; Zhu et al.; p.481, right col., bottom of page)
(“We present Everflow, a scalable packet-level telemetry system for large DCNs. Everflow leverages switch’s “match and mirror” capability to capture consistent traces of packets across DCN components and injects guided probes to actively replay packet traces.”; Zhu et al.; p.490, left col., bottom of page)
(where
“matches any rule, the switch will mirror it and encapsulate…prevent mirroring a mirrored packet”/”distinguish from regular data traffic…trace all the protocol traffic”/”Match and mirror on switch…First…Second…”/”switch’s “match and mirror” capability to capture consistent traces” maps to “execute, by packet trace workers, a capture state machine”, “switch will mirror it”/”switch’s…capture” maps to “execute, by packet trace workers”, “switch’s” maps to “trace workers” “capture” maps to “capture”, “matches any rule” with the exclusion of “prevent mirroring a mirrored packet” is considered as requiring “state” to perform “exclusion”, ““match and mirror” capability” maps to “machine”
capture packets from the packet-switched network, including packets from a host device, the captured packets including a second set of tracing packets, the first set of tracing packets comprising the second set of tracing packets, wherein capturing packets comprises:
(“…The controller also provides APIs which allow Everflow applications to query analysis results, customize counters on the analyzers, inject guided probes, and mark the debug bit on hosts. We describe the analyzer and controller in this section and the reshuffler and storage in §6.”; Zhu et al.; p.483, left col., bottom of page)
(where
“inject guided probes, and mark the debug bit on hosts”/”capture consistent traces of packets” maps to “capture packets from the packet-switched network, including packets from a host device, the captured packets including a second set of tracing packets, the first set of tracing packets comprising the second set of tracing packets”, where “hosts” maps to “including packets from a host device”, marked packets maps to “first set of tracing packets”, “capture consistent traces of packets” maps to “second set of tracing packets”, where the injected associated with captured maps to “comprising…”
submitting capture rules to the packet trace workers; and
(where
“installing a small number of well-chosen match-and-mirror rules”/” switch’s “match and mirror” capability to capture consistent traces of packets across DCN components” maps to “submitting capture rules to the packet trace workers”, where “installing” maps to “submitting”, “match-and-mirror rules”/“match and mirror” capability to capture” maps to “capture rules”, “switch’s” maps to “trace workers”,
causing the packet trace workers to capture packets based on the capture
rules;
(“First, we design matching rules to capture every flow in DCNs….”; Zhu et al.; p.481, right col., middle of page)
(where
“First, we design matching rules to capture every flow in DCNs….”/” switch’s “match and mirror” capability to capture consistent traces of packets” maps to “causing the packet trace workers to capture packets based on the capture rules”, where “design” maps to “causing”, “switch’s” maps to “packet trace workers”, “capture consistent traces of packets” maps to “capture packets”, “matching rules to capture” maps to “based on the capture rules”
identify the second set of tracing packets within the captured packets using the tag;
(where
“In the switches, we install a rule to trace any packet with the “debug” bit set””/”switch’s “match and mirror” capability to capture consistent traces of packets” maps to “identify the second set of tracing packets within the captured packets using the tag”, where “trace” maps to “identify”, “packet with the “debug” bit set”” maps to “second set of tracking packets”, “capture consistent traces of packets” maps to “capture packets”, “trace any packet with the “debut” bit set” maps to “using the tag”
identify, using the second set of tracing packets and the first set of tracing packets, a dropped or … tracing packet;
(“Further, guided probing is useful in overcoming the limitations of passive tracing. In the example of Fig 1(b), we can inject multiple copies of p into switch S2 to see whether p is dropped persistently or not. In addition, we can craft probe packets with different patterns (e.g., 5-tuples) to see if the drops are random or specific to certain 5-tuples. Such probing cannot debug transient faults because they may disappear before probing is initiated. We consider this limitation acceptable because persistent faults usually have a more severe impact than transient ones.”; Zhu et al.; p.483, left col, top of page)
(where
“we can inject multiple copies of p into switch S2 to see whether p is dropped persistently or not” maps to “identify, using the second set of tracing packets and the first set of tracing packets, a dropped or … tracing packet”, where “dropped” maps to “dropped”
identify, for the dropped or … tracing packet, using the network topology, a last-visited network node; and
(“For each complete packet trace, the analyzer checks for two types of problems: loop and drop. A loop exhibits as the same device appearing multiple times in the trace. A drop is detected when the last hop of the trace is different
from the expected last hop(s) which can be computed using the DCN topology and routing policy. For example, the expected last hop of a packet destined to an internal IP address of the DCN is the ToR switch directly connected to the IP
address. The expected last hops of a packet destined to an external IP address are the border switches of the DCN.”; Zhu et al.; p.483, right col., middle of page)
(where
“A drop is detected when the last hop of the trace is different
from the expected last hop(s) which can be computed using the DCN topology” maps to “identify, for the dropped or … tracing packet, using the network topology, a last-visited network node”, where “drop is detected…trace is different” maps to “identity, for the dropped or…tracing packet”, “using the DCN topology” maps to “using the network topology”, “last hop” maps to “a last-visited network node”
…
Zhu et al. teaches determining the topology of a network based on injection of tracing packets and teaches installing switches with rules for capturing packets, where performing the capturing of packets is segmented based on differing conditions where probe packets are injected into the network with a “debug” bit for determining whether to capture a packet or not capture the packet and teaches determining a last hop for a marked/traced packet.
Zhu et al. as described above does not explicitly teach:
generate a network performance report indicating the dropped or corrupted tracing packet and the last-visited network node.
However, Liu et al. further teaches a trace report capability which includes:
generate a network performance report indicating the dropped or … tracing packet and the last-visited network node.
(“The next three columns (the Local Drop Rate column, the WAN Drop Rate column, and the Remote Drop Rate column) of trace report 188 may be used by the network operator to identify a location in the network where a particular flow is suffering from packet drop. The Local Drop Rate column indicates the percentage of packets dropped by the local edge node, the WAN Drop Rate column indicates the percentage of packets dropped by WAN (e.g., the Internet) and the Remote Drop Rate column indicates the percentage of packets dropped by the remote edge node.”; Liu et al.; 0059)
(see FIG. 3)
(where
“identify a location in the network where a particular flow is suffering from packet drop”/“last hop sent”/”hop device”/”Upstream Hop 1”/”Upstream Hop 2”/”Downstream Hop 1”/”Downstream Hop 2”/”Local Drop Rate”/”Remote Drop Rate”/”1.05%”/”0.0”/”0.3%”/”Trace Report 188”FIG. 3 maps to “generate a network performance report indicating the dropped tracing packet and the last-visited network node”, “1.05%/”0.0%”/”0.3%”/”Trace Report 188”/FIG. 3 maps to “generate a network performance report”, “Local Drop Rate”/”Remote Drop Rate” maps to “indicating the dropped tracing packet”, “last hop sent”/”hop device”/” “identify a location in the network where a particular flow is suffering from packet drop” maps to “last-visited network node”
Liu et al. teaches injecting tracing packets associated with a flow with a trace identification and configuring devices within a system architecture with filtering to determine location(s) where packets are being dropped and then displaying the results in a trace report.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the trace report capability of Liu et al. into Zhu et al. By modifying the processing/communications of Zhu et al. to include the trace report capability as taught by the processing/communications of Liu et al., the benefits of reduced tracing overhead (Zhu et al.; p.481, middle of page) with improved tracing (Liu et al.; 0014) are achieved.
However, Shevach et al. further teaches a corrupt/LLDP/drop capability which includes:
(“The intermediate communication device 110 is configured to filter, drop, or otherwise prevent forwarding (referred to herein as “filtering”) of corrupted packets”; Shevach et al.; 0026)
(“At block 308, an indication of the count of the at least one purposely corrupted packet and the selected additional packets that are transmitted from the first communication to the second communication device via the port is provided to the second communication device. For example, the switch S1 generates and transmits the indication 220, 250, or 280 to the second communication device. In an embodiment, the indication of the count is included as an advertisement of a link layer discovery protocol (LLDP) frame. In another embodiment, providing the count includes populating a field in a diagnostic packet to indicate the count of packets that are transmitted.”; Shevach et al.; 0054)
(where
“purposely corrupted packet and the selected additional packets that are transmitted”/”the indication of the count is included as an advertisement of a link layer discovery protocol (LLDP) frame. In another embodiment, providing the count includes populating a field in a diagnostic packet to indicate the count of packets that are transmitted.” Maps to “…corrupted tracing packet”, where “corrupted packet” maps to “corrupted…packet”, “LLDP” maps to “tracing”, where purposely communicating a corrupted packet and reporting the results via LLDP is considered as “tracing”
Additionally, “drop, or otherwise prevent forwarding (referred to herein as “filtering”) of corrupted packets” is considered as indicating “corrupted packets” are analogous to a packet which is dropped.
(where
“the switch S2 determines that the switch S2 is directly connected where the RX packet indicator is greater than a percentage threshold of the TX packet indicator (e.g., greater than 80%, 90%, or another suitable percentage of the TX packet indicator). The switch S2 utilizes the predetermined threshold to account for purposely corrupted packets that may have been dropped for reasons other than their purposeful corruption” maps to “[identify]…corrupted tracing packet, [using the network topology, a last visited network node]”, where “purposely corrupted packets” maps to “corrupted tracing packet”, “switch S2 is directly connected” maps to “[using the network topology, a last visited network node]”
(where
“the switch S2 determines that the switch S2 is directly connected where the RX packet indicator is greater than a percentage threshold of the TX packet indicator (e.g., greater than 80%, 90%, or another suitable percentage of the TX packet indicator)…purposely corrupted packets” maps to “[generate a network performance report indicating the]…corrupted tracking packet [and the last-visited network node]”, where “greater than 80%” maps to “[generate a network performance report indicating the]”, “purposely corrupted packets” maps to “corrupted tracing packet”, “switch S2” maps to “[and the last-visited network node]”
Shevach et al. teaches communicating of corrupted packets and reporting the associated count via LLDP and also teaches a corrupted packet is analogous to a dropped packet.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the corrupt/LLDP/drop capability of Shevach et al. into Zhu et al. By modifying the processing/communications of Zhu et al. to include the corrupt/LLDP/drop capability as taught by the processing/communications of Shevach et al., the benefits of reduced tracing overhead (Zhu et al.; p.481, middle of page) with improved communication diagnostics (Shevach et al.; Abstract) are achieved.
As to claim 3:
Zhu et al. as described above does not explicitly teach:
identify packet latency using the network topology, wherein the network performance report further indicates network latency for a network node.
However, Liu et al. further teaches a trace report capability which includes:
identify packet latency using the network topology, wherein the network performance report further indicates network latency for a network node.
(“The next two columns (the Jitter column and the Latency column) of trace report 188 indicate the metrics of each particular flow. The Jitter column indicates the jitter (i.e., the variation in latency of packets carrying voice or video data over a communications channel) experienced by each hop of each flow, as measured in milliseconds. The Latency column indicates the latency (i.e., the time for a data packet to travel from one designated point to another) experienced by each hop of each flow, as measured in milliseconds. While user interface page 300 displays the jitter and latency metrics in units of milliseconds, user interface page 300 may display the jitter and latency metrics in any suitable unit (e.g., microseconds, seconds, etc.).”; Liu et al.; 0060)
(see FIG. 3)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the trace report capability of Liu et al. into Zhu et al. By modifying the processing/communications of Zhu et al. to include the trace report capability as taught by the processing/communications of Liu et al., the benefits of reduced tracing overhead (Zhu et al.; p.481, middle of page) with improved tracing (Liu et al.; 0014) are achieved.
As to claim 4:
Zhu et al. discloses:
identify a packet source communicatively coupled to the packet switched network; and
identify a packet destination communicatively coupled to the packet switched network, wherein the host device comprises the packet source or the packet destination, and wherein the network topology comprises the network nodes communicatively disposed between the packet source and the packet destination.
(“…The controller also provides APIs which allow Everflow applications to query analysis results, customize counters on the analyzers, inject guided probes, and mark the debug bit on hosts. We describe the analyzer and controller in this section and the reshuffler and storage in §6.”; Zhu et al.; p.483, left col., bottom of page)
(see Figure 4, Figure 7a)
As to claim 5:
Zhu et al. as described above does not explicitly teach:
display the network performance report in a user interface (UI).
However, Liu et al. further teaches a trace report capability which includes:
display the network performance report in a user interface (UI).
(“The next two columns (the Jitter column and the Latency column) of trace report 188 indicate the metrics of each particular flow. The Jitter column indicates the jitter (i.e., the variation in latency of packets carrying voice or video data over a communications channel) experienced by each hop of each flow, as measured in milliseconds. The Latency column indicates the latency (i.e., the time for a data packet to travel from one designated point to another) experienced by each hop of each flow, as measured in milliseconds. While user interface page 300 displays the jitter and latency metrics in units of milliseconds, user interface page 300 may display the jitter and latency metrics in any suitable unit (e.g., microseconds, seconds, etc.).”; Liu et al.; 0060)
(see FIG. 3)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the trace report capability of Liu et al. into Zhu et al. By modifying the processing/communications of Zhu et al. to include the trace report capability as taught by the processing/communications of Liu et al., the benefits of reduced tracing overhead (Zhu et al.; p.481, middle of page) with improved tracing (Liu et al.; 0014) are achieved.
As to claim 8:
Zhu et al. discloses:
A computer-implemented method comprising:
collecting topology data for a packet-switched network;
(“Latency profiler. Many DCN services, e.g., search and distributed memory cache, require low latency. To find out why the latency between any pair of servers is too high, the latency profiler will first mark the debug bit of the TCP
SYN packets between the two servers. From the traces of these packets, it knows the network devices on the path and then launches guided probes to measure the per-hop latency. Guided probing measures the roundtrip latency of each link instead of the one-way latency. This degree of localization suffices in practice. With this localization information, the profiler can quickly identify the network devices that cause the problem”; Zhu et al.; p.484, right col., middle of page)
(“For each complete packet trace, the analyzer checks for two types of problems: loop and drop. A loop exhibits as the same device appearing multiple times in the trace. A drop is detected when the last hop of the trace is different
from the expected last hop(s) which can be computed using the DCN topology and routing policy. For example, the expected last hop of a packet destined to an internal IP address of the DCN is the ToR switch directly connected to the IP
address. The expected last hops of a packet destined to an external IP address are the border switches of the DCN.”; Zhu et al.; pl 483, right col., middle of page)
(“We present Everflow, a network telemetry systemthat provides
scalable and flexible access to packet-level information in large DCNs. To consistently trace individual packets across the network, Everflow uses “match and mirror." Commodity switches can apply actions on packets that match on
flexible patterns over packet headers or payloads; we use this functionality with mirroring packets to our analysis servers as the action. By installing a small number of well-chosen match-and-mirror rules means we can reap the benefits of packet-level tracing while cutting down the overhead by several orders of magnitude.”; Zhu et al.; p.480, left col., top of page)
(where
“From the traces of these packets, it knows the network devices on the path”/”using the DCN topology”/”switches can apply actions on packets”/Figure 4/Figure 7a/Figure 10b maps to “collect topology data for a packet-switched network”, “knows the network devices on the path” maps to “collect topology data”, “switches…packets” maps to “packet-switched network”, where Figures 4, 7a and 10b illustrate “network”
build a network topology of network nodes of the packet-switched network, using the topology data;
(“We now present the trace collection and analysis pipeline of Everflow. As shown in Fig 4, it consists of four key components: the controller, analyzer, storage and reshuffler. On top of that, there are a variety of applications that use the packet-level information provided by Everflow to debug network faults. The controller coordinates the other components and interacts with the applications. During initialization, it configures the rules on switches. Packets that match these rules will be mirrored to the reshufflers and the directed to the analyzers which output the analysis results into storage. The controller also provides APIs which allow Everflow applications to query analysis results, customize counters on the analyzers, inject guided probes, and mark the debug bit on hosts. We describe the analyzer and controller in this section and the reshuffler and storage in §6.”; Zhu et al.; p.483, left col., bottom of page)
“From the traces of these packets, it knows the network devices on the path”/”using the DCN topology”/”switches can apply actions on packets”/Figure 4/Figure 7a/Figure 10b/”switches” maps to “build a network topology of network nodes of the packet-switched network, using the topology data”, where “switches” maps to “network nodes”
tag a first set of tracing packets with a tag;
(“To support such flexible tracing, we allow the packets to be marked by a special “debug” bit in the header. The marking criteria can be defined in any manner, as long as the total tracing overhead stays below a threshold. In the switches, we install a rule to trace any packet with the “debug” bit set”; Zhu et al.; p.481, right col., bottom of page)
(where
“allow the packets to be marked by a special “debug” bit in the header. The marking criteria can be defined in any manner, as long as the total tracing overhead stays below a threshold. In the switches, we install a rule to trace any packet with the “debug” bit set” maps to “tag a first set of tracing packets with a tag”, “marked” maps to “tag a”, “packets…trace” maps to “first set of tracing packets”, ““debug” bit” maps to “with a tag”
execute, by packet trace workers, a capture state machine;
(“When a packet matches any rule, the switch will mirror it and encapsulate the mirrored packet using GRE (Generic Routing Encapsulation). Fig. 6 shows the format of the GRE packet, where the source IP is the switch loopback IP, the destination IP is the VIP of the reshufflers, and the payload
is the original packet (starting from the L2 header). Inside the GRE header, there is a protocol field which is used to indicate that this is an Everflow mirrored packet. We configure every switch with a blacklist rule to prevent mirroring a mirrored packet.”; Zhu et al.; p.485, right col., middle of page)
(“Finally, our tracing coverage goes beyond data packets. A DCN has a small amount of traffic associated with network protocols such as BGP, PFC, and RDMA.We call it protocol traffic to distinguish from regular data traffic. Although the absolute volume of the protocol traffic is small, it is critical for the overallDCN health and performance. Thus, Everflow has rules to trace all the protocol traffic.”; Zhu et al.; p.482, left col., middle of page)
(“Match and mirror on switch…First…Second…”; Zhu et al.; p.481, right col., bottom of page)
(“We present Everflow, a scalable packet-level telemetry system for large DCNs. Everflow leverages switch’s “match and mirror” capability to capture consistent traces of packets across DCN components and injects guided probes to actively replay packet traces.”; Zhu et al.; p.490, left col., bottom of page)
(where
“matches any rule, the switch will mirror it and encapsulate…prevent mirroring a mirrored packet”/”distinguish from regular data traffic…trace all the protocol traffic”/”Match and mirror on switch…First…Second…”/”switch’s “match and mirror” capability to capture consistent traces” maps to “execute, by packet trace workers, a capture state machine”, “switch will mirror it”/”switch’s…capture” maps to “execute, by packet trace workers”, “switch’s” maps to “trace workers” “capture” maps to “capture”, “matches any rule” with the exclusion of “prevent mirroring a mirrored packet” is considered as requiring “state” to perform “exclusion”, ““match and mirror” capability” maps to “machine”
capture packets from the packet-switched network, including packets from a host device, the captured packets including a second set of tracing packets, the first set of tracing packets comprising the second set of tracing packets, wherein capturing packets comprises:
(“…The controller also provides APIs which allow Everflow applications to query analysis results, customize counters on the analyzers, inject guided probes, and mark the debug bit on hosts. We describe the analyzer and controller in this section and the reshuffler and storage in §6.”; Zhu et al.; p.483, left col., bottom of page)
(where
“inject guided probes, and mark the debug bit on hosts”/”capture consistent traces of packets” maps to “capture packets from the packet-switched network, including packets from a host device, the captured packets including a second set of tracing packets, the first set of tracing packets comprising the second set of tracing packets”, where “hosts” maps to “including packets from a host device”, marked packets maps to “first set of tracing packets”, “capture consistent traces of packets” maps to “second set of tracing packets”, where the injected associated with captured maps to “comprising…”
submitting capture rules to the packet trace workers; and
(where
“installing a small number of well-chosen match-and-mirror rules”/” switch’s “match and mirror” capability to capture consistent traces of packets across DCN components” maps to “submitting capture rules to the packet trace workers”, where “installing” maps to “submitting”, “match-and-mirror rules”/“match and mirror” capability to capture” maps to “capture rules”, “switch’s” maps to “trace workers”,
causing the packet trace workers to capture packets based on the capture
rules;
(“First, we design matching rules to capture every flow in DCNs….”; Zhu et al.; p.481, right col., middle of page)
(where
“First, we design matching rules to capture every flow in DCNs….”/” switch’s “match and mirror” capability to capture consistent traces of packets” maps to “causing the packet trace workers to capture packets based on the capture rules”, where “design” maps to “causing”, “switch’s” maps to “packet trace workers”, “capture consistent traces of packets” maps to “capture packets”, “matching rules to capture” maps to “based on the capture rules”
identify the second set of tracing packets within the captured packets using the tag;
(where
“In the switches, we install a rule to trace any packet with the “debug” bit set””/”switch’s “match and mirror” capability to capture consistent traces of packets” maps to “identify the second set of tracing packets within the captured packets using the tag”, where “trace” maps to “identify”, “packet with the “debug” bit set”” maps to “second set of tracking packets”, “capture consistent traces of packets” maps to “capture packets”, “trace any packet with the “debut” bit set” maps to “using the tag”
identify, using the second set of tracing packets and the first set of tracing packets, a dropped or … tracing packet;
(“Further, guided probing is useful in overcoming the limitations of passive tracing. In the example of Fig 1(b), we can inject multiple copies of p into switch S2 to see whether p is dropped persistently or not. In addition, we can craft probe packets with different patterns (e.g., 5-tuples) to see if the drops are random or specific to certain 5-tuples. Such probing cannot debug transient faults because they may disappear before probing is initiated. We consider this limitation acceptable because persistent faults usually have a more severe impact than transient ones.”; Zhu et al.; p.483, left col, top of page)
(where
“we can inject multiple copies of p into switch S2 to see whether p is dropped persistently or not” maps to “identify, using the second set of tracing packets and the first set of tracing packets, a dropped or … tracing packet”, where “dropped” maps to “dropped”
identify, for the dropped or … tracing packet, using the network topology, a last-visited network node; and
(“For each complete packet trace, the analyzer checks for two types of problems: loop and drop. A loop exhibits as the same device appearing multiple times in the trace. A drop is detected when the last hop of the trace is different
from the expected last hop(s) which can be computed using the DCN topology and routing policy. For example, the expected last hop of a packet destined to an internal IP address of the DCN is the ToR switch directly connected to the IP
address. The expected last hops of a packet destined to an external IP address are the border switches of the DCN.”; Zhu et al.; p.483, right col., middle of page)
(where
“A drop is detected when the last hop of the trace is different
from the expected last hop(s) which can be computed using the DCN topology” maps to “identify, for the dropped or … tracing packet, using the network topology, a last-visited network node”, where “drop is detected…trace is different” maps to “identity, for the dropped or…tracing packet”, “using the DCN topology” maps to “using the network topology”, “last hop” maps to “a last-visited network node”
…
Zhu et al. teaches determining the topology of a network based on injection of tracing packets and teaches installing switches with rules for capturing packets, where performing the capturing of packets is segmented based on differing conditions where probe packets are injected into the network with a “debug” bit for determining whether to capture a packet or not capture the packet and teaches determining a last hop for a marked/traced packet.
Zhu et al. as described above does not explicitly teach:
generate a network performance report indicating the dropped or corrupted tracing packet and the last-visited network node.
However, Liu et al. further teaches a trace report capability which includes:
generate a network performance report indicating the dropped or … tracing packet and the last-visited network node.
(“The next three columns (the Local Drop Rate column, the WAN Drop Rate column, and the Remote Drop Rate column) of trace report 188 may be used by the network operator to identify a location in the network where a particular flow is suffering from packet drop. The Local Drop Rate column indicates the percentage of packets dropped by the local edge node, the WAN Drop Rate column indicates the percentage of packets dropped by WAN (e.g., the Internet) and the Remote Drop Rate column indicates the percentage of packets dropped by the remote edge node.”; Liu et al.; 0059)
(see FIG. 3)
(where
“identify a location in the network where a particular flow is suffering from packet drop”/“last hop sent”/”hop device”/”Upstream Hop 1”/”Upstream Hop 2”/”Downstream Hop 1”/”Downstream Hop 2”/”Local Drop Rate”/”Remote Drop Rate”/”1.05%”/”0.0”/”0.3%”/”Trace Report 188”FIG. 3 maps to “generate a network performance report indicating the dropped tracing packet and the last-visited network node”, “1.05%/”0.0%”/”0.3%”/”Trace Report 188”/FIG. 3 maps to “generate a network performance report”, “Local Drop Rate”/”Remote Drop Rate” maps to “indicating the dropped tracing packet”, “last hop sent”/”hop device”/” “identify a location in the network where a particular flow is suffering from packet drop” maps to “last-visited network node”
Liu et al. teaches injecting tracing packets associated with a flow with a trace identification and configuring devices within a system architecture with filtering to determine location(s) where packets are being dropped and then displaying the results in a trace report.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the trace report capability of Liu et al. into Zhu et al. By modifying the processing/communications of Zhu et al. to include the trace report capability as taught by the processing/communications of Liu et al., the benefits of reduced tracing overhead (Zhu et al.; p.481, middle of page) with improved tracing (Liu et al.; 0014) are achieved.
However, Shevach et al. further teaches a corrupt/LLDP/drop capability which includes:
(“The intermediate communication device 110 is configured to filter, drop, or otherwise prevent forwarding (referred to herein as “filtering”) of corrupted packets”; Shevach et al.; 0026)
(“At block 308, an indication of the count of the at least one purposely corrupted packet and the selected additional packets that are transmitted from the first communication to the second communication device via the port is provided to the second communication device. For example, the switch S1 generates and transmits the indication 220, 250, or 280 to the second communication device. In an embodiment, the indication of the count is included as an advertisement of a link layer discovery protocol (LLDP) frame. In another embodiment, providing the count includes populating a field in a diagnostic packet to indicate the count of packets that are transmitted.”; Shevach et al.; 0054)
(where
“purposely corrupted packet and the selected additional packets that are transmitted”/”the indication of the count is included as an advertisement of a link layer discovery protocol (LLDP) frame. In another embodiment, providing the count includes populating a field in a diagnostic packet to indicate the count of packets that are transmitted.” Maps to “…corrupted tracing packet”, where “corrupted packet” maps to “corrupted…packet”, “LLDP” maps to “tracing”, where purposely communicating a corrupted packet and reporting the results via LLDP is considered as “tracing”
Additionally, “drop, or otherwise prevent forwarding (referred to herein as “filtering”) of corrupted packets” is considered as indicating “corrupted packets” are analogous to a packet which is dropped.
(where
“the switch S2 determines that the switch S2 is directly connected where the RX packet indicator is greater than a percentage threshold of the TX packet indicator (e.g., greater than 80%, 90%, or another suitable percentage of the TX packet indicator). The switch S2 utilizes the predetermined threshold to account for purposely corrupted packets that may have been dropped for reasons other than their purposeful corruption” maps to “[identify]…corrupted tracing packet, [using the network topology, a last visited network node]”, where “purposely corrupted packets” maps to “corrupted tracing packet”, “switch S2 is directly connected” maps to “[using the network topology, a last visited network node]”
(where
“the switch S2 determines that the switch S2 is directly connected where the RX packet indicator is greater than a percentage threshold of the TX packet indicator (e.g., greater than 80%, 90%, or another suitable percentage of the TX packet indicator)…purposely corrupted packets” maps to “[generate a network performance report indicating the]…corrupted tracking packet [and the last-visited network node]”, where “greater than 80%” maps to “[generate a network performance report indicating the]”, “purposely corrupted packets” maps to “corrupted tracing packet”, “switch S2” maps to “[and the last-visited network node]”
Shevach et al. teaches communicating of corrupted packets and reporting the associated count via LLDP and also teaches a corrupted packet is analogous to a dropped packet.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the corrupt/LLDP/drop capability of Shevach et al. into Zhu et al. By modifying the processing/communications of Zhu et al. to include the corrupt/LLDP/drop capability as taught by the processing/communications of Shevach et al., the benefits of reduced tracing overhead (Zhu et al.; p.481, middle of page) with improved communication diagnostics (Shevach et al.; Abstract) are achieved.
As to claim 10:
Zhu et al. as described above does not explicitly teach:
identify packet latency using the network topology, wherein the network performance report further indicates network latency for a network node.
However, Liu et al. further teaches a trace report capability which includes:
identify packet latency using the network topology, wherein the network performance report further indicates network latency for a network node.
(“The next two columns (the Jitter column and the Latency column) of trace report 188 indicate the metrics of each particular flow. The Jitter column indicates the jitter (i.e., the variation in latency of packets carrying voice or video data over a communications channel) experienced by each hop of each flow, as measured in milliseconds. The Latency column indicates the latency (i.e., the time for a data packet to travel from one designated point to another) experienced by each hop of each flow, as measured in milliseconds. While user interface page 300 displays the jitter and latency metrics in units of milliseconds, user interface page 300 may display the jitter and latency metrics in any suitable unit (e.g., microseconds, seconds, etc.).”; Liu et al.; 0060)
(see FIG. 3)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the trace report capability of Liu et al. into Zhu et al. By modifying the processing/communications of Zhu et al. to include the trace report capability as taught by the processing/communications of Liu et al., the benefits of reduced tracing overhead (Zhu et al.; p.481, middle of page) with improved tracing (Liu et al.; 0014) are achieved.
As to claim 11:
Zhu et al. discloses:
identify a packet source communicatively coupled to the packet switched network; and
identify a packet destination communicatively coupled to the packet switched network, wherein the host device comprises the packet source or the packet destination, and wherein the network topology comprises the network nodes communicatively disposed between the packet source and the packet destination.
(“…The controller also provides APIs which allow Everflow applications to query analysis results, customize counters on the analyzers, inject guided probes, and mark the debug bit on hosts. We describe the analyzer and controller in this section and the reshuffler and storage in §6.”; Zhu et al.; p.483, left col., bottom of page)
(see Figure 4, Figure 7a)
As to claim 12:
Liu et al. discloses:
Zhu et al. as described above does not explicitly teach:
display the network performance report in a user interface (UI).
However, Liu et al. further teaches a trace report capability which includes:
display the network performance report in a user interface (UI).
(“The next two columns (the Jitter column and the Latency column) of trace report 188 indicate the metrics of each particular flow. The Jitter column indicates the jitter (i.e., the variation in latency of packets carrying voice or video data over a communications channel) experienced by each hop of each flow, as measured in milliseconds. The Latency column indicates the latency (i.e., the time for a data packet to travel from one designated point to another) experienced by each hop of each flow, as measured in milliseconds. While user interface page 300 displays the jitter and latency metrics in units of milliseconds, user interface page 300 may display the jitter and latency metrics in any suitable unit (e.g., microseconds, seconds, etc.).”; Liu et al.; 0060)
(see FIG. 3)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the trace report capability of Liu et al. into Zhu et al. By modifying the processing/communications of Zhu et al. to include the trace report capability as taught by the processing/communications of Liu et al., the benefits of reduced tracing overhead (Zhu et al.; p.481, middle of page) with improved tracing (Liu et al.; 0014) are achieved.
As to claim 14:
Zhu et al. discloses:
wherein each packet of the first set of tracing packets has a common network flow 5-tuple.
(“We ran the packet drop debugger to investigate this issue. From the drop debugger,we observed thatmany SYN packet traces that did not reach the DIPs after traversing the Muxes and that all these abnormal traces stalled one hop before the same switch S. The drop debugger subsequently launched guided probes, with the same 5-tuples as the dropped SYN packets, to S to validate the drops. The results showed that all the SYN packets destined to a specific DIP were dropped by S, suggesting that S was blackholing the packets to the DIP (Fig 8).”; Zhu et al.; p.487, top of page)
As to claim 15:
Zhu et al. discloses:
A computer storage device having computer-executable instructions
stored thereon, which, on execution by a computer, cause the computer to perform operations comprising:
collecting topology data for a packet-switched network;
(“Latency profiler. Many DCN services, e.g., search and distributed memory cache, require low latency. To find out why the latency between any pair of servers is too high, the latency profiler will first mark the debug bit of the TCP
SYN packets between the two servers. From the traces of these packets, it knows the network devices on the path and then launches guided probes to measure the per-hop latency. Guided probing measures the roundtrip latency of each link instead of the one-way latency. This degree of localization suffices in practice. With this localization information, the profiler can quickly identify the network devices that cause the problem”; Zhu et al.; p.484, right col., middle of page)
(“For each complete packet trace, the analyzer checks for two types of problems: loop and drop. A loop exhibits as the same device appearing multiple times in the trace. A drop is detected when the last hop of the trace is different
from the expected last hop(s) which can be computed using the DCN topology and routing policy. For example, the expected last hop of a packet destined to an internal IP address of the DCN is the ToR switch directly connected to the IP
address. The expected last hops of a packet destined to an external IP address are the border switches of the DCN.”; Zhu et al.; pl 483, right col., middle of page)
(“We present Everflow, a network telemetry systemthat provides
scalable and flexible access to packet-level information in large DCNs. To consistently trace individual packets across the network, Everflow uses “match and mirror." Commodity switches can apply actions on packets that match on
flexible patterns over packet headers or payloads; we use this functionality with mirroring packets to our analysis servers as the action. By installing a small number of well-chosen match-and-mirror rules means we can reap the benefits of packet-level tracing while cutting down the overhead by several orders of magnitude.”; Zhu et al.; p.480, left col., top of page)
(where
“From the traces of these packets, it knows the network devices on the path”/”using the DCN topology”/”switches can apply actions on packets”/Figure 4/Figure 7a/Figure 10b maps to “collect topology data for a packet-switched network”, “knows the network devices on the path” maps to “collect topology data”, “switches…packets” maps to “packet-switched network”, where Figures 4, 7a and 10b illustrate “network”
build a network topology of network nodes of the packet-switched network, using the topology data;
(“We now present the trace collection and analysis pipeline of Everflow. As shown in Fig 4, it consists of four key components: the controller, analyzer, storage and reshuffler. On top of that, there are a variety of applications that use the packet-level information provided by Everflow to debug network faults. The controller coordinates the other components and interacts with the applications. During initialization, it configures the rules on switches. Packets that match these rules will be mirrored to the reshufflers and the directed to the analyzers which output the analysis results into storage. The controller also provides APIs which allow Everflow applications to query analysis results, customize counters on the analyzers, inject guided probes, and mark the debug bit on hosts. We describe the analyzer and controller in this section and the reshuffler and storage in §6.”; Zhu et al.; p.483, left col., bottom of page)
“From the traces of these packets, it knows the network devices on the path”/”using the DCN topology”/”switches can apply actions on packets”/Figure 4/Figure 7a/Figure 10b/”switches” maps to “build a network topology of network nodes of the packet-switched network, using the topology data”, where “switches” maps to “network nodes”
tag a first set of tracing packets with a tag;
(“To support such flexible tracing, we allow the packets to be marked by a special “debug” bit in the header. The marking criteria can be defined in any manner, as long as the total tracing overhead stays below a threshold. In the switches, we install a rule to trace any packet with the “debug” bit set”; Zhu et al.; p.481, right col., bottom of page)
(where
“allow the packets to be marked by a special “debug” bit in the header. The marking criteria can be defined in any manner, as long as the total tracing overhead stays below a threshold. In the switches, we install a rule to trace any packet with the “debug” bit set” maps to “tag a first set of tracing packets with a tag”, “marked” maps to “tag a”, “packets…trace” maps to “first set of tracing packets”, ““debug” bit” maps to “with a tag”
execute, by packet trace workers, a capture state machine;
(“When a packet matches any rule, the switch will mirror it and encapsulate the mirrored packet using GRE (Generic Routing Encapsulation). Fig. 6 shows the format of the GRE packet, where the source IP is the switch loopback IP, the destination IP is the VIP of the reshufflers, and the payload
is the original packet (starting from the L2 header). Inside the GRE header, there is a protocol field which is used to indicate that this is an Everflow mirrored packet. We configure every switch with a blacklist rule to prevent mirroring a mirrored packet.”; Zhu et al.; p.485, right col., middle of page)
(“Finally, our tracing coverage goes beyond data packets. A DCN has a small amount of traffic associated with network protocols such as BGP, PFC, and RDMA.We call it protocol traffic to distinguish from regular data traffic. Although the absolute volume of the protocol traffic is small, it is critical for the overallDCN health and performance. Thus, Everflow has rules to trace all the protocol traffic.”; Zhu et al.; p.482, left col., middle of page)
(“Match and mirror on switch…First…Second…”; Zhu et al.; p.481, right col., bottom of page)
(“We present Everflow, a scalable packet-level telemetry system for large DCNs. Everflow leverages switch’s “match and mirror” capability to capture consistent traces of packets across DCN components and injects guided probes to actively replay packet traces.”; Zhu et al.; p.490, left col., bottom of page)
(where
“matches any rule, the switch will mirror it and encapsulate…prevent mirroring a mirrored packet”/”distinguish from regular data traffic…trace all the protocol traffic”/”Match and mirror on switch…First…Second…”/”switch’s “match and mirror” capability to capture consistent traces” maps to “execute, by packet trace workers, a capture state machine”, “switch will mirror it”/”switch’s…capture” maps to “execute, by packet trace workers”, “switch’s” maps to “trace workers” “capture” maps to “capture”, “matches any rule” with the exclusion of “prevent mirroring a mirrored packet” is considered as requiring “state” to perform “exclusion”, ““match and mirror” capability” maps to “machine”
capture packets from the packet-switched network, including packets from a host device, the captured packets including a second set of tracing packets, the first set of tracing packets comprising the second set of tracing packets, wherein capturing packets comprises:
(“…The controller also provides APIs which allow Everflow applications to query analysis results, customize counters on the analyzers, inject guided probes, and mark the debug bit on hosts. We describe the analyzer and controller in this section and the reshuffler and storage in §6.”; Zhu et al.; p.483, left col., bottom of page)
(where
“inject guided probes, and mark the debug bit on hosts”/”capture consistent traces of packets” maps to “capture packets from the packet-switched network, including packets from a host device, the captured packets including a second set of tracing packets, the first set of tracing packets comprising the second set of tracing packets”, where “hosts” maps to “including packets from a host device”, marked packets maps to “first set of tracing packets”, “capture consistent traces of packets” maps to “second set of tracing packets”, where the injected associated with captured maps to “comprising…”
submitting capture rules to the packet trace workers; and
(where
“installing a small number of well-chosen match-and-mirror rules”/” switch’s “match and mirror” capability to capture consistent traces of packets across DCN components” maps to “submitting capture rules to the packet trace workers”, where “installing” maps to “submitting”, “match-and-mirror rules”/“match and mirror” capability to capture” maps to “capture rules”, “switch’s” maps to “trace workers”,
causing the packet trace workers to capture packets based on the capture
rules;
(“First, we design matching rules to capture every flow in DCNs….”; Zhu et al.; p.481, right col., middle of page)
(where
“First, we design matching rules to capture every flow in DCNs….”/” switch’s “match and mirror” capability to capture consistent traces of packets” maps to “causing the packet trace workers to capture packets based on the capture rules”, where “design” maps to “causing”, “switch’s” maps to “packet trace workers”, “capture consistent traces of packets” maps to “capture packets”, “matching rules to capture” maps to “based on the capture rules”
identify the second set of tracing packets within the captured packets using the tag;
(where
“In the switches, we install a rule to trace any packet with the “debug” bit set””/”switch’s “match and mirror” capability to capture consistent traces of packets” maps to “identify the second set of tracing packets within the captured packets using the tag”, where “trace” maps to “identify”, “packet with the “debug” bit set”” maps to “second set of tracking packets”, “capture consistent traces of packets” maps to “capture packets”, “trace any packet with the “debut” bit set” maps to “using the tag”
identify, using the second set of tracing packets and the first set of tracing packets, a dropped or … tracing packet;
(“Further, guided probing is useful in overcoming the limitations of passive tracing. In the example of Fig 1(b), we can inject multiple copies of p into switch S2 to see whether p is dropped persistently or not. In addition, we can craft probe packets with different patterns (e.g., 5-tuples) to see if the drops are random or specific to certain 5-tuples. Such probing cannot debug transient faults because they may disappear before probing is initiated. We consider this limitation acceptable because persistent faults usually have a more severe impact than transient ones.”; Zhu et al.; p.483, left col, top of page)
(where
“we can inject multiple copies of p into switch S2 to see whether p is dropped persistently or not” maps to “identify, using the second set of tracing packets and the first set of tracing packets, a dropped or … tracing packet”, where “dropped” maps to “dropped”
identify, for the dropped or … tracing packet, using the network topology, a last-visited network node; and
(“For each complete packet trace, the analyzer checks for two types of problems: loop and drop. A loop exhibits as the same device appearing multiple times in the trace. A drop is detected when the last hop of the trace is different
from the expected last hop(s) which can be computed using the DCN topology and routing policy. For example, the expected last hop of a packet destined to an internal IP address of the DCN is the ToR switch directly connected to the IP
address. The expected last hops of a packet destined to an external IP address are the border switches of the DCN.”; Zhu et al.; p.483, right col., middle of page)
(where
“A drop is detected when the last hop of the trace is different
from the expected last hop(s) which can be computed using the DCN topology” maps to “identify, for the dropped or … tracing packet, using the network topology, a last-visited network node”, where “drop is detected…trace is different” maps to “identity, for the dropped or…tracing packet”, “using the DCN topology” maps to “using the network topology”, “last hop” maps to “a last-visited network node”
…
Zhu et al. teaches determining the topology of a network based on injection of tracing packets and teaches installing switches with rules for capturing packets, where performing the capturing of packets is segmented based on differing conditions where probe packets are injected into the network with a “debug” bit for determining whether to capture a packet or not capture the packet and teaches determining a last hop for a marked/traced packet.
Zhu et al. as described above does not explicitly teach:
generate a network performance report indicating the dropped or corrupted tracing packet and the last-visited network node.
However, Liu et al. further teaches a trace report capability which includes:
generate a network performance report indicating the dropped or … tracing packet and the last-visited network node.
(“The next three columns (the Local Drop Rate column, the WAN Drop Rate column, and the Remote Drop Rate column) of trace report 188 may be used by the network operator to identify a location in the network where a particular flow is suffering from packet drop. The Local Drop Rate column indicates the percentage of packets dropped by the local edge node, the WAN Drop Rate column indicates the percentage of packets dropped by WAN (e.g., the Internet) and the Remote Drop Rate column indicates the percentage of packets dropped by the remote edge node.”; Liu et al.; 0059)
(see FIG. 3)
(where
“identify a location in the network where a particular flow is suffering from packet drop”/“last hop sent”/”hop device”/”Upstream Hop 1”/”Upstream Hop 2”/”Downstream Hop 1”/”Downstream Hop 2”/”Local Drop Rate”/”Remote Drop Rate”/”1.05%”/”0.0”/”0.3%”/”Trace Report 188”FIG. 3 maps to “generate a network performance report indicating the dropped tracing packet and the last-visited network node”, “1.05%/”0.0%”/”0.3%”/”Trace Report 188”/FIG. 3 maps to “generate a network performance report”, “Local Drop Rate”/”Remote Drop Rate” maps to “indicating the dropped tracing packet”, “last hop sent”/”hop device”/” “identify a location in the network where a particular flow is suffering from packet drop” maps to “last-visited network node”
Liu et al. teaches injecting tracing packets associated with a flow with a trace identification and configuring devices within a system architecture with filtering to determine location(s) where packets are being dropped and then displaying the results in a trace report.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the trace report capability of Liu et al. into Zhu et al. By modifying the processing/communications of Zhu et al. to include the trace report capability as taught by the processing/communications of Liu et al., the benefits of reduced tracing overhead (Zhu et al.; p.481, middle of page) with improved tracing (Liu et al.; 0014) are achieved.
However, Shevach et al. further teaches a corrupt/LLDP/drop capability which includes:
(“The intermediate communication device 110 is configured to filter, drop, or otherwise prevent forwarding (referred to herein as “filtering”) of corrupted packets”; Shevach et al.; 0026)
(“At block 308, an indication of the count of the at least one purposely corrupted packet and the selected additional packets that are transmitted from the first communication to the second communication device via the port is provided to the second communication device. For example, the switch S1 generates and transmits the indication 220, 250, or 280 to the second communication device. In an embodiment, the indication of the count is included as an advertisement of a link layer discovery protocol (LLDP) frame. In another embodiment, providing the count includes populating a field in a diagnostic packet to indicate the count of packets that are transmitted.”; Shevach et al.; 0054)
(where
“purposely corrupted packet and the selected additional packets that are transmitted”/”the indication of the count is included as an advertisement of a link layer discovery protocol (LLDP) frame. In another embodiment, providing the count includes populating a field in a diagnostic packet to indicate the count of packets that are transmitted.” Maps to “…corrupted tracing packet”, where “corrupted packet” maps to “corrupted…packet”, “LLDP” maps to “tracing”, where purposely communicating a corrupted packet and reporting the results via LLDP is considered as “tracing”
Additionally, “drop, or otherwise prevent forwarding (referred to herein as “filtering”) of corrupted packets” is considered as indicating “corrupted packets” are analogous to a packet which is dropped.
(where
“the switch S2 determines that the switch S2 is directly connected where the RX packet indicator is greater than a percentage threshold of the TX packet indicator (e.g., greater than 80%, 90%, or another suitable percentage of the TX packet indicator). The switch S2 utilizes the predetermined threshold to account for purposely corrupted packets that may have been dropped for reasons other than their purposeful corruption” maps to “[identify]…corrupted tracing packet, [using the network topology, a last visited network node]”, where “purposely corrupted packets” maps to “corrupted tracing packet”, “switch S2 is directly connected” maps to “[using the network topology, a last visited network node]”
(where
“the switch S2 determines that the switch S2 is directly connected where the RX packet indicator is greater than a percentage threshold of the TX packet indicator (e.g., greater than 80%, 90%, or another suitable percentage of the TX packet indicator)…purposely corrupted packets” maps to “[generate a network performance report indicating the]…corrupted tracking packet [and the last-visited network node]”, where “greater than 80%” maps to “[generate a network performance report indicating the]”, “purposely corrupted packets” maps to “corrupted tracing packet”, “switch S2” maps to “[and the last-visited network node]”
Shevach et al. teaches communicating of corrupted packets and reporting the associated count via LLDP and also teaches a corrupted packet is analogous to a dropped packet.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the corrupt/LLDP/drop capability of Shevach et al. into Zhu et al. By modifying the processing/communications of Zhu et al. to include the corrupt/LLDP/drop capability as taught by the processing/communications of Shevach et al., the benefits of reduced tracing overhead (Zhu et al.; p.481, middle of page) with improved communication diagnostics (Shevach et al.; Abstract) are achieved.
As to claim 17:
Liu et al. discloses:
identify a packet source communicatively coupled to the packet switched network; and
identify a packet destination communicatively coupled to the packet switched network, wherein the host device comprises the packet source or the packet destination, and wherein the network topology comprises the network nodes communicatively disposed between the packet source and the packet destination.
(“Trace parameters 180 of user interface page 200 are characteristics associated with an application that are used to trace the application through network 110. In the illustrated embodiment of FIG. 2, trace parameters 180 are included at the top of user interface page 200. Trace parameters 180 include a site identification (represented as Site ID), a VPN identification of the complaining user (represented as VPN), an IP address of the complaining user's device (represented as Host IP), a destination IP address (represented as Destination IP/FQDN), an identification of the application (represented as Application), and a duration for the network path trace (represented as Trace Duration). The site identification indicates the location of user device 122 relative to a network. For example, the site identification may be a unique identifier of a site in an SD-WAN overlay network. The VPN identification is the VPN identification of the complaining user. While the trace duration is represented as seconds in FIG. 2, the trace duration may be represented in any increment of time (e.g., milliseconds, minutes, etc.). In certain embodiments, the trace duration of FIG. 2 may be replaced with a number of packets such that the network path trace terminates once the number of packets input in user interface page 200 are filtered in accordance with a filter policy. Trace parameters 180 may be represented by numerals, letters, characters, or a combination thereof. In certain embodiments, an asterisk located next to a particular trace parameter 180 (i.e., the site identification and the VPN identification) indicates that this field is mandatory to initiate a network path trace.”; Liu et al.; 0053)
(see FIG. 1)
As to claim 18:
Liu et al. discloses:
display the network performance report in a user interface (UI).
(see FIG. 1 and FIG. 3)
Claim(s) 2, 9 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al., “Packet-Level Telemetry in Large Datacenter Networks”, August 17-21, 2015, SIGCOMM ’15, pp. 479-491 in view of Liu et al. US 20230112928 (cited in Non-Final Rejection dated 1/28/2026) and in further view of Shevach et al. US 20170034003 (cited in Non-Final Rejection dated 1/28/2026) and Pronk et al. US 20220263723 (cited in Non-Final Rejection dated 1/28/2026).
As to claim 2:
Zhu et al. as described above does not explicitly teach:
identifying a trigger condition for collecting the topology data, the trigger condition comprising receiving an indication of a network error from a network user or ….
However, Pronk et al. further teaches a topology/fault/user-chosen capability which includes:
identifying a trigger condition for collecting the topology data, the trigger condition comprising receiving an indication of a network error from a network user or ….
(“The HF network topology graph 44 can be computed for a user-chosen analysis time interval, so that for example if a network fault is identified which has been observed only for the last 24 hours then the network topology discovery process 40 can be applied for an analysis time interval of only the last 24 hours in order to visualize the network topology with the fault. Optionally, the network topology discovery process 40 can also be run for an earlier analysis time interval prior to when the network fault arose, and comparison of these “before and after” HF network topologies may localize the fault to the region where these two topologies differ.”; Pronk et al.; 0041)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the topology/fault/user-chosen capability of Pronk et al. into Zhu et al. By modifying the processing/communications of Zhu et al. to include the topology/fault/user-chosen capability as taught by the processing/communications of Pronk et al., the benefits of reduced tracing overhead (Zhu et al.; p.481, middle of page) with improved quality (Pronk et al.; 0051) are achieved.
As to claim 9:
Zhu et al. as described above does not explicitly teach:
identifying a trigger condition for collecting the topology data, the trigger condition comprising receiving an indication of a network error from a network user or ….
However, Pronk et al. further teaches a topology/fault/user-chosen capability which includes:
identifying a trigger condition for collecting the topology data, the trigger condition comprising receiving an indication of a network error from a network user or ….
(“The HF network topology graph 44 can be computed for a user-chosen analysis time interval, so that for example if a network fault is identified which has been observed only for the last 24 hours then the network topology discovery process 40 can be applied for an analysis time interval of only the last 24 hours in order to visualize the network topology with the fault. Optionally, the network topology discovery process 40 can also be run for an earlier analysis time interval prior to when the network fault arose, and comparison of these “before and after” HF network topologies may localize the fault to the region where these two topologies differ.”; Pronk et al.; 0041)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the topology/fault/user-chosen capability of Pronk et al. into Zhu et al. By modifying the processing/communications of Zhu et al. to include the topology/fault/user-chosen capability as taught by the processing/communications of Pronk et al., the benefits of reduced tracing overhead (Zhu et al.; p.481, middle of page) with improved quality (Pronk et al.; 0051) are achieved.
As to claim 16:
Zhu et al. as described above does not explicitly teach:
identifying a trigger condition for collecting the topology data, the trigger condition comprising receiving an indication of a network error from a network user or ….
However, Pronk et al. further teaches a topology/fault/user-chosen capability which includes:
identifying a trigger condition for collecting the topology data, the trigger condition comprising receiving an indication of a network error from a network user or ….
(“The HF network topology graph 44 can be computed for a user-chosen analysis time interval, so that for example if a network fault is identified which has been observed only for the last 24 hours then the network topology discovery process 40 can be applied for an analysis time interval of only the last 24 hours in order to visualize the network topology with the fault. Optionally, the network topology discovery process 40 can also be run for an earlier analysis time interval prior to when the network fault arose, and comparison of these “before and after” HF network topologies may localize the fault to the region where these two topologies differ.”; Pronk et al.; 0041)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the topology/fault/user-chosen capability of Pronk et al. into Zhu et al. By modifying the processing/communications of Zhu et al. to include the topology/fault/user-chosen capability as taught by the processing/communications of Pronk et al., the benefits of reduced tracing overhead (Zhu et al.; p.481, middle of page) with improved quality (Pronk et al.; 0051) are achieved.
Claim(s) 6, 13 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al., “Packet-Level Telemetry in Large Datacenter Networks”, August 17-21, 2015, SIGCOMM ’15, pp. 479-491 in view of Liu et al. US 20230112928 (cited in Non-Final Rejection dated 1/28/2026) and in further view of Shevach et al. US 20170034003 (cited in Non-Final Rejection dated 1/28/2026) and Ashlock et al. US 20250039057 (cited in Non-Final Rejection dated 1/28/2026).
As to claim 6:
Zhu et al. as described above does not explicitly teach:
remove the tag from packets of the second set of tracing packets.
However, Ashlock et al. further teaches a remove capability which includes:
remove the tag from packets of the second set of tracing packets.
(“As shown in FIG. 5D, router B may process synthetic probe packet 306a and its SRv6 uSID, removing the label associated with router B, and forwarding the packet on to router E. In FIG. 5E, router E may perform a similar function, removing its own label from the header of packet 306a and forwarding it on to router F. Finally, as shown in FIG. 5F, router F may process packet 306a, removing its SRv6 header, and forwarding it on to destination 304.”; Ashlock et al.; 0053)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the topology/fault/user-chosen capability of Ashlock et al. into Zhu et al. By modifying the processing/communications of Zhu et al. to include the topology/fault/user-chosen capability as taught by the processing/communications of Ashlock et al., the benefits of improved probing (Ashlock et al.; Abstract) are achieved.
As to claim 13:
Zhu et al. as described above does not explicitly teach:
remove the tag from packets of the second set of tracing packets.
However, Ashlock et al. further teaches a remove capability which includes:
remove the tag from packets of the second set of tracing packets.
(“As shown in FIG. 5D, router B may process synthetic probe packet 306a and its SRv6 uSID, removing the label associated with router B, and forwarding the packet on to router E. In FIG. 5E, router E may perform a similar function, removing its own label from the header of packet 306a and forwarding it on to router F. Finally, as shown in FIG. 5F, router F may process packet 306a, removing its SRv6 header, and forwarding it on to destination 304.”; Ashlock et al.; 0053)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the topology/fault/user-chosen capability of Ashlock et al. into Zhu et al. By modifying the processing/communications of Zhu et al. to include the topology/fault/user-chosen capability as taught by the processing/communications of Ashlock et al., the benefits of improved probing (Ashlock et al.; Abstract) are achieved.
As to claim 19:
Zhu et al. as described above does not explicitly teach:
remove the tag from packets of the second set of tracing packets.
However, Ashlock et al. further teaches a remove capability which includes:
remove the tag from packets of the second set of tracing packets.
(“As shown in FIG. 5D, router B may process synthetic probe packet 306a and its SRv6 uSID, removing the label associated with router B, and forwarding the packet on to router E. In FIG. 5E, router E may perform a similar function, removing its own label from the header of packet 306a and forwarding it on to router F. Finally, as shown in FIG. 5F, router F may process packet 306a, removing its SRv6 header, and forwarding it on to destination 304.”; Ashlock et al.; 0053)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the topology/fault/user-chosen capability of Ashlock et al. into Zhu et al. By modifying the processing/communications of Zhu et al. to include the topology/fault/user-chosen capability as taught by the processing/communications of Ashlock et al., the benefits of improved probing (Ashlock et al.; Abstract) are achieved.
Allowable Subject Matter
Claim(s) 21 and 22 is/are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL K PHILLIPS whose telephone number is (571)272-1037. The examiner can normally be reached M-F 8am-10am, 1pm-5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the Examiner by telephone are unsuccessful, the examiner’s supervisor, Ricky Ngo can be reached on 571-272-3139. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
MICHAEL K. PHILLIPS
Examiner
Art Unit 2464
/MICHAEL K PHILLIPS/Examiner, Art Unit 2464
Prosecution Insights