Hi Eddie, Is DCCP dead? Hell no! It's at a minimum a highly valuable platform for research into congestion control algorithms and how applications can benefit from and cope with those algorithms. Can a real (non-research) application use it today? Maybe, if the app is deployed in constrained circumstances (on a single managed network) and the app developers can find/create a good-enough-quality DCCP implementation. Will such an app emerge? Well, no one is beating down our doors right now. Could a general-Internet-wide-deployment application use DCCP today? Hell no! Many of the reasons for that are enumerated in rosenberg-hourglass. You may disagree with the long-term implications of that draft, but from an application developer's point of view, it very accurately describes the current state. If DCCP had transparent NAT-traversal could a general-deployment app use DCCP? Maybe (availability of quality implementations is still a problem, among others). Would such an app emerge? Well, again, no one is beating down our doors. Will NATs with DCCP understanding ever be widely deployed in the Internet? I believe that people who think they will are ignoring fundamental economic processes. Many people at the IETF seem to argue that fundamental economic processes are not the IETF's business. To me, that's akin to designing a building for Southern California and ignoring earthquakes. No matter how beautiful your building is, if it's going to collapse in a minor earthquake it isn't good architecture. But this is a much bigger topic than DCCP. Will transparent NAT traversal be the deciding factor in the success of DCCP? Once more, hell no! DCCP is a highly complex protocol, its benefits are difficult to explain to people who would prefer to ignore the problems it solves (that's a good chuck of application developers) and it requires those people to change their ways of thinking. These factors are all independent of NAT traversal. Transparent NAT traversal for DCCP will make our lives easier though. Structured Stream Transport -- that's the thing that was presented at tsvwg in Vancouver? That was very interesting, but it seemed to me that the only really new ground it broke was running the protocol over UDP instead of natively and writing an application that actually took advantage of things that you can do with SCTP. I'm not convinced that it's necessary to reinvent transport protocols just to get NAT traversal (and get around the rosenberg-hourglass problem). Tom P. > -----Original Message----- > From: Eddie Kohler [mailto:kohler@xxxxxxxxxxx] > Sent: Tuesday, February 26, 2008 5:31 PM > To: Phelan, Tom > Cc: Colin Perkins; 'dccp' working group > Subject: Re: draft-phelan-dccp-natencap-00.txt > > This mail is a somewhat disconnected response to the whole thread. > > - Like Colin I am skeptical of the benefits of standardizing a UDP > encapsulation. > > - NAT traversal is a problem. > > - draft-rosenberg-hourglass is an overstatement and I'm fundamentally > against it. > > - draft-iab-protocol-success is not normative. > > - DCCP is not perfect. > > - If DCCP is considered dead without NAT traversal, and if NAT traversal > for > DCCP is considered impossible, then it'd be better to design a new > congestion > control protocol intended to layer over UDP than to design a DCCP-in-UDP > layer. Such a protocol could fix some of DCCP's design mistakes and would > avoid warty duplication of functionality between DCCP and UDP headers. > > - I don't consider DCCP dead without NAT traversal. > > - I think NAT traversal for DCCP will happen; among other things it is > easy > for NATs to do (by design). > > - If DCCP is dead, the reason is not the protocol number, but rather that > we > made mistakes in the analysis of the problem -- for instance, maybe there > is > no great upswelling of need for either congestion controlled UDP or for > new > congestion control algorithms -- or in our design assumptions -- for > instance, > maybe minimal protocol headers aren't worth the pain they cause. > > - I'm not sure DCCP is dead. > > - Structured Stream Transport's worth a look anyway. > > http://www.bford.info/pub/net/sst.pdf > > Eddie > > > Phelan, Tom wrote: > > Hi Colin, > > > > So there are two independent threads to your comment below -- one, is > > what DCCP-NAT is trying to achieve worthwhile? And two, what's the best > > way to go about it? > > > > On the first issue, I'd love to hear your detailed thinking. What got > > me thinking seriously about the need for DCCP-NAT was > > draft-iab-protocol-success. One of the factors for initial success that > > it points out is incremental deployment. DCCP-RAW doesn't have that. > > For DCCP-RAW to be useable in the general Internet, it requires entities > > that have nothing to gain from DCCP deployment to make changes (the NAT > > vendors). Some people argue that there are some market pressures that > > could pull the NAT vendors to support DCCP, but I see these scenarios as > > having slim chance of success. > > > > It didn't seem to me to be too difficult to define a UDP-encapsulation > > for DCCP that would be supported by NATs, and the potential benefit of > > that support seems much greater than the effort to me. Some of these > > benefits seem very near-term to me. > > > > For example, it's currently very difficult for me (and most other people > > too, I think) to offer a DCCP demo application that can be accessed by a > > large public. I have no easy access to a host outside of a NAT on which > > I can run arbitrary code. On the other hand, I have no problem finding > > hosts behind NATs on which I can do absolutely anything I desire. So > > with DCCP-NAT it's much easier to expand the group of people > > experimenting with DCCP and also expand the opportunities for > > interactions among the various groups. > > > > Of course just having DCCP-NAT will hardly be the one thing that breaks > > DCCP into wild (or even initial) success, but I do believe it will make > > early experimentation easier and will be necessary (but not sufficient) > > for eventual initial success. > > > > As far as the second issue, I'll put that in another e-mail. > > > > Tom P. > > > >> -----Original Message----- > >> From: Colin Perkins [mailto:csp@xxxxxxxxxxxxx] > >> Sent: Sunday, February 17, 2008 9:57 AM > >> To: Phelan, Tom > >> Cc: Ian McDonald; 'dccp' working group > >> Subject: Re: draft-phelan-dccp-natencap-00.txt > >> > >> Hi, > >> > >> On 14 Feb 2008, at 20:13, Phelan, Tom wrote: > >>> It's definitely my intention that DCCP-NAT happens in the end > >>> nodes. It > >>> isn't intended to be some middlebox intercepting a DCCP stream and > >>> converting it. The end nodes originate the packets with DCCP-NAT > >>> encapsulation. I'll try to make that more clear in the next > > revision. > >>> Nice to hear about NAT for DCCP(-RAW) in Linux. To expand a bit on > >>> the > >>> above paragraph, I wouldn't expect DCCP-NAT in Linux to be > > implemented > >>> below the DCCP layer as I imagine NAT for DCCP is. In my view, the > >>> encapsulation to use (NAT, RAW, IPv4, IPv6) is chosen by the > >>> application > >>> and implemented (mostly) within the DCCP layer. > >> Allowing the application to choose runs into connectivity problems > >> when some applications support the UDP encapsulation, and some do > >> not. If we're going to define a UDP encapsulation - and it's not at > >> all clear to me that such a thing is a good idea - then I'd recommend > >> that we do so in a way that it can be done by the DCCP stack, > >> transparently to the applications, with a well-defined order for > >> trying native vs. encapsulated connection requests. > >> > >> -- > >> Colin Perkins > >> http://csperkins.org/ > >> > >
