Rajiv Asati (rajiva) said the following on 11/24/2008 04:05 PM:
When this draft-shen-udp-traceroute-ext was presented last week during
the int-area meeting, there seems to be a consensus about the problem
that the draft was solving, however, there was a minor concern about the
solution.
Specifically, the concern was that using last 4 bits in the
UDP src port# will result in varying the src port#, hence,
traceroute probe may not really test the actual path (if
multiple paths exist) that the application traffic may take.
If the application, uses this draft, assuming the higher than 4 bits
is the PID of the process, and last 4 bits is the offset. Then both
numbers don't change, thus the hashing results will still stay the same.
No difference from using just the PID in src port# in the current scheme.
If we are talking about trace from two different routers/hosts, then
even the PID might be different in the current scheme. So basically
there is no change in this regard(multipath).
thanks.
- Naiming
Well, this concern shouldn't really exist wrt the proposal, since the
current UDP traceroute implementation mandates varying the UDP source
port# (as well as dest port#) with every probe anyway. In other words,
the path that the UDP traceroute packet takes will vary with every probe
anyway.
So, the port hashing, NAT etc. related points should not be
related to this proposal.
So, this proposal preseves the current UDP traceroute behavior and
doesn't make it any better or worse from the forwarding perspective. Of
course, the proposal is advantageous since it makes the delivery of ICMP
related info selective and a bit secured.
Would welcome your feedback.
Cheers,
Rajiv
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
