RE: draft-ietf-ccamp-tracereq

[Ron Bonica <[e-mail]>]

Xiaoming,

I am not familiar with any traceroute implementations that use TCP. Could
you point me at a reference?

Why would TCP be preferable to UDP. Since you only expect one response to
each probe, what value would TCP add?

                                                            Ron

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Xiaoming Fu
> Sent: Wednesday, June 04, 2003 6:12 AM
> To: Ron Bonica
> Cc: [e-mail]
> Subject: Re: draft-ietf-ccamp-tracereq
>
>
> Ron,
>
> Thanks for your new version. One more issue:
>
> Current available transport mechanisms for traceroute include ICMP, UDP,
> and TCP. UDP may relief DoS issues, but NAT/firewall might be another
> issue (although we could have STUN). TCP has an issue of connection
> setup latency, however it could be potentially considered (it may also
> have a number of available ports?). To my knowledge, circulations from
> one protocol to protocol are sometimes helpful, for example, SIP
> initially used UDP, while TCP was recently proposed.
>
> Hence, I would suggest a "SHOULD" instead of "MUST" in Section 4.2.
>
> Cheers,
> Xiaoming
>
> Ron Bonica wrote:
> > Xiaoming,
> >
> > Thanks for the thorough review. A new version of the draft is
> available at
> > http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-04.txt.
> >
> >                               Ron
> >
> >
> >
> >>-----Original Message-----
> >>From: [e-mail] [mailto:[e-mail]]On
> >>Behalf Of Xiaoming Fu
> >>Sent: Friday, May 30, 2003 7:20 PM
> >>To: Ron Bonica
> >>Cc: [e-mail]
> >>Subject: Re: draft-ietf-ccamp-tracereq
> >>
> >>
> >>Ron,
> >>
> >>It is a nice document. I went it through and have a few comments:
> >>
> >>- Section 3, 9) - "forwarding plane failu res" ==> _failures_
> >
> >
> > Oops....
> >
> >
> >>- I didn't understand why the following paragraph appears twice - the
> >>   same in Section 3, 13) and 14). I assume you're talking about control
> >>   plane failure in 13).
> >>       Justification: MTU information is sometimes useful in identifying
> >>       the root cause of forwarding plane failures.
> >
> >
> > You have a point. MTU information, in either direction, can be useful in
> > debugging
> > both control and forwarding plane failures. The paragraph should read as
> > follows in
> > both 3.13 and 3.14:
> >
> > Justification: MTU information is sometimes useful in identifying
> > the root cause of forwarding and control plane failures.
> >
> >
> >>- Again, Section 3, 14):
> >>       14) When tracing through the forwarding plane, display the MTU
> >>       associated with each hop in the reverse direction.
> >>   Meanwhile, in Section 4.3:
> >>       The protocol must be stateless. That is, nodes should not have to
> >>       maintain state between successive traceroute messages.
> >>   Are you assuming the probe and response messages are always
> hop-by-hop
> >>   addressed? Otherwise, the forwarding and reverse paths of
> transporting
> >>   the probe & response pair could differ, e.g., due to the Internet
> >>   routing, or policies. And -
> >>   Do we need a same transport path for them? If so, how a stateless
> >>   traceroute protocol knows the reverse path to forward the response
> >>   message?  Probably we could create a temporary state while handling a
> >>   probe message, to include P_HOP & Interface information like in RSVP,
> >>   although the state is used only once in this case.
> >
> >
> > Requirements 13 and 14 are ambiguous. As a result, you have interpretted
> > them
> > in a manner that was not intended. They should be restated as follows:
> >
> > 13) When tracing through the control plane, display the MTU
> associated with
> > interface
> > that forwards datagrams through the traced path.
> >
> > 14) When tracing through the forwarding plane, display the MTU
> associated
> > with each
> > interface that receives datagtrams along the traced path.
> >
> >
> >>- Section 4.1 - I don't understand the following sentense:
> >>                              Many network forward datagrams
> that specify
> >>     IP options differently than they would forward datagrams
> that do not
> >>     specify IP options.
> >>   Maybe they ==> them, but the implication of this sentense is still
> >>   unclear to me.
> >
> >
> > This paragraph should read as follows:
> >
> > Many networks forward datagrams that specify IP options differently than
> > they would forward datagrams that do not specify IP options. Therefore,
> > the introductions of IP options would cause the application to trace a
> > forwarding path other than the path that its user intended to trace.
> >
> >
> >>- Section 4.2 "IP was _disqualified_ in order to conserve protocol
> >>    identifiers." - I'm not sure this is always valid. Anyway,
> >>    using UDP would have also to request a port number from IANA; there
> >>    is actually a tradeoff among protocol_ID v.s. port number v.s. ICMP
> >>    type. BTW, UDP may introduce a little (although minor)
> >>    additional overhead.
> >
> >
> > IANA is much more willing to assign UDP port numbers than protocol-IDs.
> > This is because there are so many more UDP port numbers available.
> >
> >
> >>- In general I would expect the document would not constrain too much
> >>   on protocol details - the latter looks to me more of a protocol
> >>   design issue, instead of an informational RFC on "requirement".
> >
> >
> > In principle, I agree. Section 4 provides just enough protocol
> requirements
> > to keep protocol designers away from some known bad design
> approaches. For
> > example,
> > years ago we tried returning MPLS information in ICMP
> datagrams. This wasn't
> > well received. So, the requirements document guides us around that bad
> > approach.
> >
> >
> >>- It looks better if an experimental traceroute protocol (RFC1393 -
> >>   traceroute using an IP option) would be referenced and shortly
> >>   introduced in Section 2 (e.g., MTU determination).
> >
> >
> > I thought about referencing RFC 1393 but decided not to because
> it is not
> > widely known or implemented.
> >
> >                                              Ron
> >
> >
> >>My 2 cents.
> >>
> >>Xiaoming
> >>
> >>Ron Bonica wrote:
> >>
> >>>Folks,
> >>>
> >>>At the request of the IESG, I have updated
> draft-ietf-ccamp-tracereq and
> >>>sent a new copy to the draft editor. Until the draft editor
> >>
> >>posts it, a copy
> >>
> >>>can be found at
> >
> > http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-03.txt.
> >
> >>Please take a look, as this draft will need to go through
> another WG last
> >>call.
> >>
> >>===========================================
> >>Ronald P. Bonica       Ph: 703 886 1681
> >>vBNS Engineering       page: 1 888 268 8021
> >>Ashburn, Va.
> >>===========================================
> >>"We are not on Earth to guard a museum, but
> >>to cultivate a flourishing garden of life."
> >>                -- Angelo Giuseppe Roncalli
> >>
> >>
>
>