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.
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
