[e2e] Multiple TCP-friendly Sessions and Cong. Control in user-mode?

[Shivkumar Kalyanaraman]

> > Sounds consistent. But, is this argument well recognized in the brave new
> > world where applications run over UDP/RTP and do their own CC? Are
> > application developers implementing congestion control at the app layer ?
> > How far is the CM or other approaches gaining traction with end-system
> > designers?
> >
>
> Some applications do their own CC because they, rightly or wrongly,
> perceive TCP as being too "heavyweight".  Some just don't need reliable
> transfer but want to be responsible citizens.  This is all part of the
> justification for DCP. Indeed, a good argument for not putting CC in
> user space is that getting congestion control right is not easy and
> applications can get it wrong.
>
> See:
> http://www.ietf.org/internet-drafts/draft-floyd-dcp-problem-00.txt
> http://www.ietf.org/internet-drafts/draft-kohler-dcp-02.txt


Quickly read it. sounds like a reasonable protocol at first glance. I dont
buy the argument that we should insert CC in the kernel apps can get CC
wrong. If you really believe that, I think it is time to form a IRTF or
IETF group to document all the good things which people have done in CC;
establish the theories of getting it right; and provide several reference
designs. Sally's document does some of that; but perhaps the community
could distill its wisdom further into documents. There is nothing
preventing apps from using apps from using UDP today without CC. The
biggest incentive for applications to deploy CC is that with CC, it can
retain some control of the fate of its packets during network overload
situations.

I have a wild idea for the kernel vs user space issue; and since I am not
an OS expert, perhaps someone can correct me as to why it cannot be done.

1. Would it be possible for kernel-level to provide the basic building
   blocks like shapers, window, acks, nack, ack-vector, different RTT
   estimators etc, and allow applications to customize it through some
   kind of system call interface? Have OS people thought about how to
   allow an application can pass to the kernel a customized function which
   needs to operate at the kernel-level?

   Going on the lines of ALF, I think we should allow applications more
   ways to participate in customizing the procedures applied on its
   traffic at the lower layer.

2. I am not totally convinced about the need for acks and tight ack-based
   pacing in DCF. A rate-paced window in the forward direction plus
   output-rate feedback once an RTT would allow sparse feedback in the
   reverse direction, without the pacing function or the reliability
   function of acks.

-Shiv