[e2e] overlay over TCP

[Michael Welzl]

> > And what might be those reasons????
> > DCCP will have just about the same deployment difficulties that any other
> > new transport protocol has to jump through....
> 
> 
> Even worse for DCCP .. since its further behind SCTP.. and time
> makes a difference.. let me tell you :-D

While I'm all for DCCP, I think that its deployment is in fact a
more intricate issue:

One can easily argue that using SCTP brings a benefit for
certain special applications. That is a little more difficult
for DCCP.

>From the perspective of a programmer who ponders whether to
use the protocol, some potential immediate benefits of
DCCP to the application are:

* if the application is planned to have 1000s of users
  connect to a single server, it may work (i.e. scale) better
  because congestion control is properly implemented

* TCP-based applications that are used at the same time may
  work better

* the programmer's own application might experience a smaller
  loss ratio while maintaining reasonable throughput, i.e.
  there are perhaps greater chances that most of what I send
  really makes it to the other end, while my rate is almost
  as large as it can be under such circumstances. DCCP's
  ECN support might help here, but on the other hand, merely
  setting the ECN flag in a UDP based flow is not such a big
  deal either, provided that the OS allows doing this...


Given that we might be talking about an application which
would need to be updated to use the protocol and kind of
works already, as well as the standard deployment problems
with firewalls etc., I have doubts that these arguments
are convincing.


The DCCP problem statement draft says:

  There has been substantial agreement [RFC 2309] [FF99]
  that in order to maintain the continued use of end-to-end congestion
  control, router mechanisms are needed to detect and penalize
  uncontrolled high-bandwidth flows in times of high congestion; these
  router mechanisms are colloquially known as `penalty boxes'.


Now let's say that the only truly convincing argument to use
DCCP would be dramatically worse performance with UDP
as the result of such penalty boxes (this is what I believe).
In this case, DCCP deployment can only happen once such boxes
are widely used. An ISP will only have an incentive to install
such a box if it brings a benefit - i.e. if the financial loss
from problems with UDP traffic is greater than the loss from
customers who switch to a different ISP because their UDP
based application doesn't work anymore. If tons of apps use
UDP instead of DCCP, the latter loss may be quite significant.

So an ISP might have to wait for DCCP to be used by apps before
installing penalty boxes, which would motivate app designers
to use DCCP ... two parties waiting for each other, and what
have we learned from history?


Take a look at this paragraph about QoS deployment from RFC 2990:


  No network operator will make the significant investment in
  deployment and support of distinguished service infrastructure unless
  there is a set of clients and applications available to make
  immediate use of such facilities.  Clients will not make the
  investment in enhanced services unless they see performance gains in
  applications that are designed to take advantage of such enhanced
  services.  No application designer will attempt to integrate service
  quality features into the application unless there is a model of
  operation supported by widespread deployment that makes the
  additional investment in application complexity worthwhile and
  clients who are willing to purchase such applications.  With all
  parts of the deployment scenario waiting for the others to move,
  widespread deployment of distinguished services may require some
  other external impetus.


Will we also need such an other external impetus for DCCP,
and what could it be?


Cheers,
Michael