On Nov 20, 2009, at 9:21 PM, Phelan, Tom wrote: > 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. Hi Tom, the last was is outdated. It was written before I implemented the stuff in the SCTP implementation of FreeBSD and Mac OS X. I'm planning to update it for the next IETF. Best regards Michael > > 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. >>> >>> > >
