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:[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/
