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
> 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
> layer.  Such a protocol could fix some of DCCP's design mistakes and
> 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
> we
> made mistakes in the analysis of the problem -- for instance, maybe
> is
> no great upswelling of need for either congestion controlled UDP or
> 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,
> > what DCCP-NAT is trying to achieve worthwhile?  And two, what's the
> > way to go about it?
> >
> > On the first issue, I'd love to hear your detailed thinking.  What
> > me thinking seriously about the need for DCCP-NAT was
> > draft-iab-protocol-success.  One of the factors for initial success
> > it points out is incremental deployment.  DCCP-RAW doesn't have
> > For DCCP-RAW to be useable in the general Internet, it requires
> > that have nothing to gain from DCCP deployment to make changes (the
> > vendors).  Some people argue that there are some market pressures
> > 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
> > for DCCP that would be supported by NATs, and the potential benefit
> > that support seems much greater than the effort to me.  Some of
> > benefits seem very near-term to me.
> >
> > For example, it's currently very difficult for me (and most other
> > 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
> > I can run arbitrary code.  On the other hand, I have no problem
> > hosts behind NATs on which I can do absolutely anything I desire.
> > 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
> > DCCP into wild (or even initial) success, but I do believe it will
> > early experimentation easier and will be necessary (but not
> > 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
> >>> 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,
> >>> 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
> >> 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/
> >>
> >

Reply via email to