-
-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Calculate Forward and Backward Loss #860
Comments
fujiapple852
changed the title
Show overall trace status
Calculate Forward and Backward Loss
Aug 18, 2024
fujiapple852
added a commit
that referenced
this issue
Aug 20, 2024
fujiapple852
added a commit
that referenced
this issue
Aug 21, 2024
fujiapple852
added a commit
that referenced
this issue
Aug 21, 2024
fujiapple852
added a commit
that referenced
this issue
Aug 22, 2024
fujiapple852
added a commit
that referenced
this issue
Oct 27, 2024
fujiapple852
added a commit
that referenced
this issue
Oct 27, 2024
fujiapple852
added a commit
that referenced
this issue
Nov 3, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Idea
Calculate "forward loss" and "backward loss" heuristics and indicate these via new columns
Floss
andBloss
.Definiton
"Forward loss" for a given probe P in a given round R indicates that (i) probe P was lost in round R and (ii) all subsequent probes within round R were also lost.
"Backward loss" for a given probe P in a given round R indicates that (i) probe P was lost in round R and (ii) a prior probe within round R has forward loss.
Informally, this is intended to indicate when a probe loss is the cause of subsequent losses ("forward loss") and when a probe loss is the victim of a previous loss ("backward loss").
Example
In the following example, after initially discovering the target (10.0.0.105) at ttl=5 in round 1, packet loss occurs in all subsequent round at ttl=3. No probes are able to get beyond ttl=3 and so we observe packet loss at hops ttl=4 and ttl=5. We can determine that the loss at ttl=3 is "forward loss" in that it causes all subsequent probes (ttl=4, ttl=5) in the same round to be lost. Likewise, we can determine that hops ttl=4 and ttl=5 have "backward loss" as they have loss in rounds where a prior hop (ttl=3) has "forward loss".
Note that in the above the
Loss%
column uses the traditional calculation ((Snd - Recv) / Snd
). Similar columns could be added forFloss%
andBloss%
.Caveats
This technique is only a heuristic, it cannot conclusively determine forward and backward loss.
Every probe sent in every round is an independent trial, and so there is no guarantee that every probe within a given round will follow the same path (have the same "flow"). This invalidates the concept of forward and backward loss. We can therefore only meaningfully measure this if we can be confident all probs follow a single path. This is typically achieved (but not guaranteed) by tracing with the ICMP, UDP/Dublin or UDP/Paris strategy.
Even if a single path is followed by all probes, a given host on the path may drop packets for only a subset of probes sent within a given round, either due to rate limiting or genuine intermittent packet loss. This could result in a false positive "forward loss" for a given hop if all subsequent hops in the round showing loss which is not genuine (i.e rate limited). For example, hop with ttl=3 could be incorrectly be deemed to have "forward loss" for a given round due to observed loss from hops ttl=4 and ttl=5 which is not genuine (i.e. rate limited).
Similarly, a false positive "backward loss" could be recorded for a hop with genuine loss, if a previous hop shows loss which is not genuine (i.e. rate limited). For example, even if hop with ttl=4 has genuine loss, it will still be shown to have "backward loss" due to ttl=3.
The text was updated successfully, but these errors were encountered: