Hi Carlos,
One comment about the using IP header ID field suggestion.
I think this draft uses this src port# of udp for a couple of reasons,
- this is not a routing problem as such, it's a traceroute
application issue,
so the udp header would be more appropriate in this case. the
application
is only stuff the udp header and relies on the underline ip
infrastructure to
handle the ip portion, better for layering. we don't violate the
layering.
we want to keep the traceroute mechanism the same.
- this is not just for ipv4, and it would be for ipv6 too.
- this issue is only for UDP, the most popular traceroute
implementation.
the others, such as ICMP, TCP can easily extend things. But not
UDP. UDP
header is not extensible. The other transport can also use the same
traceroute structures, TLVs, but they have little to do with this
ori-len
mechanism described here. They can easily develop their own schemes.
thanks.
- Naiming
On Nov 24, 2008, at 6:48 PM, Carlos Pignataro wrote:
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
