Thanks, Rajiv ! To add to this, from listening to the int-area session
on streaming:
As background, existing udp-based traceroute uses the source udp port to
identify the traceroute invocation instance (by using the process ID
plus high bit set ((getpid() & 0xffff) | 0x8000)) to allow for multiple
simultaneous traceroutes from the same host), and the destination port
increasing per-probe to identify the probe.
Existing traceroute, as well udp-based application traffic expiring
mid-stream can (currently) trigger generation of ICMP timeexceeded
containing ICMP extensions.
One design goal of the proposal in draft-shen-udp-traceroute-ext is to
have minimum incremental additions/differences (to maximize backwards
compatibility) from Van Jacobson's traceroute, and to allow for easy
host implementations over traceroute-nanog/tracesroute/etc.
Regarding the (paraphrased) comments:
what if a real UDP-based app time-exceeds in transit?
That's what happens now, and it's actually one of the concerns the I-D
tries to solve. Current rules regarding what icmp multipart extension to
include (e.g., unnumbered interface info, incoming MPLS header or IP NH)
can be dependent upon policies based on addresses (source address, etc)
and not based on info contained on the probe as an authenticated request.
What about ECMP hashing on source UDP port? Is this UDP probes
being sent all over?
Unchanged from the current udp-based traceroute. What changes is that
routers can check the probe for auth and extension requests.
What about using the Ident field in the IP header instead of
source port?
I think it's a nice idea ! It makes for a solution for all transports,
but the implication of using only df=1 probes might be too constraining?
Thanks,
--Carlos.
On 11/24/2008 7:05 PM, Rajiv Asati (rajiva) said the following:
> 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
>
--
--Carlos Pignataro.
Escalation RTP - cisco Systems
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
