> -----Original Message----- > From: Phelan, Tom [mailto:tphelan@xxxxxxxxxxxx] > Sent: Tuesday, February 19, 2008 11:19 AM > To: Dan Wing; Colin Perkins > Cc: 'dccp' working group > Subject: RE: DCCP-over-UDP [was > draft-phelan-dccp-natencap-00.txt] > > Hi Dan, > > The SRV thing seems like a good way to go about finding out whether to > use DCCP-RAW or DCCP-NAT, especially considering that we > haven't defined > anything about SRV records for DCCP yet. Do we need to do something > about this in the DCCP-NAT draft? That seems like a good place right now. What needs to be thought about is how to do the two attempts so that DCCP-RAW (which is more efficient on the wire and provides additional DCCP functionality [partial checksums?]) and DCCP-UDP both get similar behavior. For example, I wouldn't want to suffer through a full DCCP-RAW connection timeout before attempting DCCP-UDP, or else DCCP will get a reputation for being 'slow'. If this approach seems useful, we should look at defining a similar mechanism for SDP, too, when that time comes around. -d > Tom P. > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > Sent: Tuesday, February 19, 2008 1:44 PM > > To: 'Colin Perkins'; Phelan, Tom > > Cc: ''dccp' working group' > > Subject: RE: DCCP-over-UDP [was > draft-phelan-dccp-natencap-00.txt] > > > > > I essentially agree with all your arguments below. There's a > > > clear short term benefit to having a UDP encapsulation for > > > DCCP to ease NAT traversal. This is the incremental > > > deployment argument from draft-iab-protocol-success, and also > > > the argument made in draft-rosenberg-internet-waist-hourglass. > > > > > > There's also a significant, long-term, architectural penalty > > > from encouraging the two existing transport protocols (TCP > > > and UDP) to become the new waist of the Internet. We don't > > > want to tunnel DCCP over UDP: it's extra overhead, and it > > > complicates firewalls, debugging, and so on. > > > > If DCCP-over-UDP is pervasive, firewalls (and IDS/IPS) will > > have to understand DCCP-over-UDP as well as DCCP itself. > > > > > Long term, we > > > should encourage NAT vendors to support new transport > > > protocols, and build native support for DCCP, SCTP, UDP-lite, etc. > > > > I agree. > > > > But first there needs to be a market pull for new protocols, > > and allowing the new protocol to run over UDP until there is > > a sufficiently large market driver to cause those vendors to > > build those products seems important. > > > > > Call me an ivory tower academic if you like (although, > > > reflecting the Glasgow style, our ivory tower is made of > > > stone <http://www.gla.ac.uk/media/media_20554_en.jpg> ), but > > > I'm not yet convinced we should give up all semblance of > > > architectural purity... > > > > I'm not a stone tower academic, and even I agree with the > > argument. > > > > DCCP has an initiation handshake. It seems effective, to me, > > to define SRV records that are something like this: > > > > _foobar._dccp SRV 0 0 1234 server.example.com. > > _foobar._dccp-udp SRV 0 0 1234 server.example.com. > > > > and protocol foobar then tries both a native DCCP handshake > > (to DCCP port 1234) and a DCCP-over-UDP handshake (to UDP > > port 1234). We could do the native DCCP first and try > > DCCP-over-UDP 100ms (or whatever you like) later. > > > > This provides the incremental deployment we need (with > > dccp-udp) and provides an easy path to real DCCP deployment > > (where the UDP encapsulation is not necessary because there > > are no meddling on-path IPv4 NATs). > > > > Would this be feasible? > > > > -d >
