[dccp] Re: Question on Middlebox Buffering of DCCP Packets

[Bill Fischofer <wtf at britestream.com>]

Ok, glad to hear I didn't miss something that was already there.  It occurred 
to me after my original note, however, that a variant of this question will 
occur in base DCCP implementations when dealing with upper-layer APIs (e.g., 
a DCCP socket interface).  

For a TCP socket the application doesn't concern itself with congestion 
control.  It simply sends data at will and relies on the fact that the OS 
will block the thread making the call if the bytes can't be sent right now.  
Similarly, UDP sockets may have packets dropped by the OS if they cannot be 
transmitted for whatever reason.  So the question is: How should a DCCP 
socket behave?

Whether or not the application can "see" the congestion control info that DCCP 
is using to rate-limit sends the question remains what does DCCP do if the 
application for whatever reason doesn't observe these rate limits?

Bill Fischofer
Britestream Networks

On Sunday 24 July 2005 12:50 pm, Eddie Kohler wrote:
> Hi Bill,
>
> The DCCP documents don't address this question.  I think the right answer
> will depend on the application.  For instance, if the data in the stream
> was MPEG video, it might make sense to drop B/P-frames, but buffer
> I-frames.  Does this need to be a negotiable feature?  We'd have to see a
> proposal -- perhaps a "drop packets after N sec of delay".  But any such
> feature is premature.  Let's implement something first and see what the
> difficulties are, if any.
>
> Eddie
>