Hi Michael, Thanks for the info on SCTP. That makes it sound like SCTP and DCCP encaps could be high-level-approach compatible. Is there a draft you're working from for SCTP encap? The last one I saw was substantially different from what you describe. Tom P. > -----Original Message----- > From: Michael Tüxen [mailto:Michael.Tuexen@xxxxxxxxxxxxxxxxx] > Sent: Friday, November 20, 2009 3:18 PM > To: Phelan, Tom > Cc: gorry@xxxxxxxxxxxxxx; Pasi Sarolahti; DCCP working group > Subject: Re: One ring to rule them all (generic UDP encap of > transports) > > On Nov 20, 2009, at 8:07 PM, Phelan, Tom wrote: > > > Hi Gorry, > > > > You've raised a couple of issues below that I think we could better keep > > track of if we have a new thread, so I've renamed the subject here. > > What I'd like to discuss here is the thought that we can have a generic > > approach to UDP encapsulation of transport protocols. Since we have no > > concrete approach on the table, it's a little difficult to comment, but > > here are my thoughts on what I've heard bandied about. > > > > Just tunnel it -- To me this means IP Header/UDP Header/IP > > Header/Transport Header. The problem is the addresses in the inner IP > > Header. In tunneling, the endpoints of the tunnel need to understand > > the addresses in the inner IP Header. But in the usual situation with > > NAT in between client and server, at least one of the addresses won't > > make sense to the receiving endpoint. That address will be from the > > private address realm of the other endpoint, and could duplicate an > > address used by another device communicating with the receiver. So what > > do you do with these inner IP addresses? Ignore them? What do you send > > in the return packets? How do you form a unique 4-tuple that identifies > > the socket (source address/port + destination address/port) when two > > endpoints could have the same source address? > > > > So drop the inner IP Header -- This gives you IP Header/UDP > > Header/Transport Header. I think of this as "encapsulation" rather than > > "tunneling". You can now make the 4-tuple from the IP addresses and the > > Transport Header ports. But this breaks the checksum in the Transport > > Header. Where are the IP addresses used in the checksum pseudo-header? > > From the IP Header? But those might be changed en route. > We use IP Header/UDP/SCTP when encapsulating SCTP in UDP. > Please note that SCTP does NOT use a pseudoheader for checksum > computation. > The SCTP checksum (actually a CRC32c) is computed only over the SCTP > packet, not taking into account anything from the IP header. > > > > So change the rules for checksums -- Fortunately, TCP, SCTP and DCCP use > > pretty much the same rules for computing the checksum field. Saying > > encapsulated transports ignore their own checksum field and use the UDP > > checksum probably works here. > > > > But has anything else been broken? -- For DCCP, yes. Partial checksums > > don't work. Also, I believe SCTP has a stronger checksum option that I > > believe has been broken by this approach so far. You still need some > > protocol-specific rules. > SCTP works, we also use the UDP checksum. Since it is computed normally > by the NIC it is not that much of a performance issue. And I thought > it is better to do the same for IPv4 and IPv6. > > > > So it looks to me like completely generic UDP encap is not possible, > > although mostly generic is possible. The mostly-generic draft would say > > use IP Header/UDP Header/Transport Header, use these generic rules for > > dealing with the encapsulated checksum, and then use these > > protocol-specific rules for dealing with protocol-specific issues. > > > > This is the approach taken by dccp-natencap, plus some additional > > optimizations -- since the DCCP checksum field is now useless, why carry > > it? And once you eliminate that, the DCCP header can be made more > > efficient. Are these additional optimizations worth it? I'd like to > > hear opinions... > We also need SCTP specific rules for dealing with multihoming and NAT > traversal... But that is specific. > > > > Note that another approach that's been talked about is to eliminate the > > ports from the inner Transport Header and use the ports in the UDP > > Header to indicate the actual application. This seems unworkable to me > > in that it means that a port can only be used for one transport and > > that's likely to break all sorts of things. > The does NOT work for SCTP, since the UDP ports on different paths might > be different, due to independent NAT boxes on different paths. SCTP, > however, > does require one port for all paths. > So for SCTP we really need the IP Header/UDP Header/SCTP Packet > approach... > > Best regards > Michael > > > > Tom P. > > > >> -----Original Message----- > >> From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf > > Of > >> Gorry Fairhurst > >> Sent: Friday, November 20, 2009 11:48 AM > >> To: Pasi Sarolahti > >> Cc: DCCP working group > >> Subject: Re: Soliciting input on UDP encapsulation for DCCP > >> > >> A few comments in-line, some of which I raised last time, but don't > >> recall the answers. > >> > >> > >> Pasi Sarolahti wrote: > >>> Hello, > >>> > >>> During the Hiroshima meeting last week some support (and some > > concerns) > >>> was voiced about working on UDP encapsulation for DCCP, with a > >>> suggestion to allocate an UDP port to be used for DCCP > > encapsulation. To > >>> make this happen, it was proposed that we bring back > >>> draft-phelan-dccp-natencap, for the WG to submit it for Experimental > >>> RFC. Tom has now updated the draft and the refreshed version can be > >>> found at http://tools.ietf.org/html/draft-phelan-dccp-natencap-03 > >>> > >>> With the above background in mind, I'm now looking for input on the > >>> following questions: > >>> > >>> a) in your opinion, should the DCCP WG start working on UDP > >>> encapsulation for DCCP? > >>> > >> No, or at least unsure. > >> > >> I'd love to see a tunnel encapsulation, however I'd also like to > >> consider the feasibility of a common method for all transports - or at > >> least one that handles UDP-Lite, SCTP and DCCP consistently with the > >> possibility of later extension. If I were in the DCCP meeting I would > >> have tried to push on this one and see what people said, hence I'd be > >> keen to seen feedback via the list. If there are good reasons to > >> continue separate approaches for each, that would be fine, but I'd > >> expect to see this rationale somewhere in the draft. > >> > >>> b) if yes, do you think draft-phelan-dccp-natencap is a good > > starting > >>> point for this, and therefore should become a WG document? > >>> > >> Maybe, although I would think it is worth considering a straight UDP > >> encapsulation that does not adjust the position and order of the > > fields. > >> > >>> In addition, please speak up if you have other technical comments > > about > >>> the draft. > >>> > >> Separate email sent to the list. > >> > >>> Thanks! > >>> > >>> - Pasi > >>> > >> > >> Finally, I think I'd say it was essential that any encapsulation draft > >> also notes the drawbacks of this mode, and hence advocates native > >> transport were possible! > >> > >> e.g. > >> No currently defined support for ECN > >> No currently defined support for shared PMTUD > >> Restricted support for partial coverage > >> > >> - The pros would seem to outweigh the cons, but there are > > disadvantages. > >> > >> Gorry > >> > >> P.S. I also believe this should be discussed at TSVWG, since there is > >> already a proposal for an SCTP encapsulation. > > > >
