Hi Dan, See inline... Tom P. > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Tuesday, February 19, 2008 3:04 PM > To: Phelan, Tom; 'Colin Perkins' > Cc: ''dccp' working group' > Subject: RE: DCCP-over-UDP [was draft-phelan-dccp-natencap-00.txt] > > > > > -----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'. > [Tom P.] Yes, the problem is how to avoid a long timeout if the first connection you try is not active. Although if it isn't active, why did anyone bother to make an SRV record for it? This will take some thought, but it does seem like something worth pursuing. > 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 > >
