Re: [dccp] draft-phelan-dccp-natencap-00.txt
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:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 5:31 PM To: Phelan, Tom Cc: Colin Perkins; 'dccp' working group Subject: Re: [dccp] 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
Re: [dccp] draft-phelan-dccp-natencap-00.txt
Hi, one question we really need to answer is whether we want to go through the pains of specifying UDP encapsulations for all our transport protocols. We have on the table: * draft-phelan-dccp-natencap for DCCP * draft-tuexen-sctp-udp-encaps for SCTP * JDR's recent email on the MMUSIC list for TCP-over-UDP All of them need to basically design very similar handshake/signaling exchanges, they all need a solution for the service identification issue, etc. This is undesirable. If we need to encapsulate something in UDP for the purposes of NAT traversal, why aren't we encapsulating IP in UDP, on top of which we can run pretty much anything? Instead of requiring that DCCP stacks grow support for DCCP-over-UDP, why don't we simply require that DCCP stacks implement Teredo or something similar? Why are we solving the NAT traversal problem protocol-by-protocol rather than one time? (The still ongoing NAT traversal discussion in HIP - which is building its own NAT traversal solution - has left me convinced that we should have pushed harder for the original just use Teredo proposal for HIP NAT traversal. We'd be long done.) Lars
Re: [dccp] draft-phelan-dccp-natencap-00.txt
Hi Lars, I sympathize with your concern for each transport inventing its own UDP encap solution. However, I don't think that that IP/UDP/IP/DCCP[SCTP][whatever] works well. What is in the inner IP addresses? They're not useful at all. They could start out the same as the outer addresses, but after traversing a NAT they wouldn't make sense to the receiving system. Can we invent a generic transport UDP encapsulation? Maybe, maybe not. I haven't seen that TCP-over-UDP thing. What kind of rationale is there for that? Tom P. -Original Message- From: Lars Eggert [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 10:19 AM To: Phelan, Tom Cc: 'dccp' working group Subject: Re: [dccp] draft-phelan-dccp-natencap-00.txt Hi, one question we really need to answer is whether we want to go through the pains of specifying UDP encapsulations for all our transport protocols. We have on the table: * draft-phelan-dccp-natencap for DCCP * draft-tuexen-sctp-udp-encaps for SCTP * JDR's recent email on the MMUSIC list for TCP-over-UDP All of them need to basically design very similar handshake/signaling exchanges, they all need a solution for the service identification issue, etc. This is undesirable. If we need to encapsulate something in UDP for the purposes of NAT traversal, why aren't we encapsulating IP in UDP, on top of which we can run pretty much anything? Instead of requiring that DCCP stacks grow support for DCCP-over-UDP, why don't we simply require that DCCP stacks implement Teredo or something similar? Why are we solving the NAT traversal problem protocol-by-protocol rather than one time? (The still ongoing NAT traversal discussion in HIP - which is building its own NAT traversal solution - has left me convinced that we should have pushed harder for the original just use Teredo proposal for HIP NAT traversal. We'd be long done.) Lars
Re: [dccp] draft-phelan-dccp-natencap-00.txt
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 - In the dark ages, IPsec ESP could not be used if you were behind a NAT. In 2001, IETF began standardizing IPsec-over-UDP [draft-ietf-ipsec-udp-encaps-00]. At roughly the same time, several NAT vendors started shipping equipment with IPsec Passthru support. In 2000, IPsec was the most popular way to connect to corporate networks, and NATs were being installed at a rapid pace. Many IPsec implementations added support for IPsec-over-UDP. To this day, IPsec-over-UDP (and IPsec-over-TCP, to a lesser degree) are sometimes necessary to establish an IPsec connection. This means that something along the path -- often a NAT -- is interfering with IKE and/or IPsec. I don't know if DCCP will encounter a greater or lesser success and IPsec (and thus will have more or fewer NATs with native DCCP support). But, like the need to still have IPsec-over-UDP on many networks, DCCP will need a fallback to a NAT-friendly protocol or DCCP won't work. I expect DCCP-over-UDP is a more appealing fallback than TCP, but I think those are the only two choices. -d 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/
Re: [dccp] draft-phelan-dccp-natencap-00.txt
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:[EMAIL PROTECTED] Sent: Sunday, February 17, 2008 9:57 AM To: Phelan, Tom Cc: Ian McDonald; 'dccp' working group Subject: Re: [dccp] 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/
Re: [dccp] draft-phelan-dccp-natencap-00.txt
Hi Colin, On the second issue in your e-mail, whether the NAT traversal mode of DCCP should be transparent to applications or not: There were a few issues that drove me towards application visibility. I felt that applications would want to know directly that NAT traversal mode was available or not and that it would be used or not. This is similar to why I perceive TLS is more popular with apps than IPsec. Apps could migrate to IPsec without making changes, yet they seem to prefer TLS. There are perhaps many reasons for this, but I think one of them is because TLS gives them more visible and direct control over what's going on. Perhaps this thinking doesn't apply here -- if NAT traversal mode were widely available in DCCP implementations and the negotiation to choose a mode was efficient then apps wouldn't care. But my initial take was that the added complexity and the likely time involved in settling on an encapsulation (if your first guess was wrong) were enough disadvantages to argue for the no-negotiation approach. Another issue with automatic negotiation is that apps that used another signaling protocol to rendezvous (such as SIP/SDP) would need to carry info for all encaps, even when they knew they needed only one (they'd need to carry the UDP port of the DCCP-NAT service, plus the DCCP port). How big an issue this is, since we're at the very early stages of defining any of these protocols, is debatable. The case isn't absolute though, so I'm perfectly willing to listen to counterarguments. Tom P. -Original Message- From: Colin Perkins [mailto:[EMAIL PROTECTED] Sent: Sunday, February 17, 2008 9:57 AM To: Phelan, Tom Cc: Ian McDonald; 'dccp' working group Subject: Re: [dccp] 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/
Re: [dccp] 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/
Re: [dccp] draft-phelan-dccp-natencap-00.txt
On Fri, Feb 15, 2008 at 1:42 PM, Dan Wing [EMAIL PROTECTED] wrote: I am guessing/hoping that Rémi's draft-denis-behave-nat-dccp-00.txt documents what the Linux DCCP NAT code does? The BEHAVE working group has a milestone to adopt a DCCP NAT document, and draft-denis-behave-nat-dccp-00.txt is the only candidate document at this point. Can you point me at that? Ian -- Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz
