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

[Eddie Kohler <kohler at cs.ucla.edu>]

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


Bill Fischofer wrote:
> I've been reading the DCCP draft specs and I don't see this question 
> addressed.  I'd appreciate either a pointer to the consensus view or else 
> discussion of this question since it seems to be germane to eventual DCCP 
> deployment.
>
> UDP-based applications aren't going to switch to DCCP overnight so for some 
> period of time it seems a worthwhile function would be for middleboxes to 
> provide protocol translation between UDP and DCCP to protect the core network 
> from the sort of uncontrolled growth in non-congestion-controlled traffic 
> that DCCP is being designed to address.
>
> Translating between DCCP and UDP seems straightforward except in the case 
> where a UDP sender is exceeding whatever congestion control limits the active 
> DCCP CC profile would impose on packet flows.  In such cases is a middlebox 
> providing UDP-to-DCCP translation services expected to buffer packets 
> arriving from the UDP sender until they are allowed to be transmitted 
> according to the DCCP CC profile in effect?  Alternatively, should the 
> middlebox simply drop the UDP packets which are arriving too quickly for the 
> CC profile?  Should this be a negotiable feature of the profile itself?
>
> I apologize if these questions have already been asked and answered.  Thank 
> you ot the list membership for whatever pointers you can provide on this 
> topic.
>
> Bill Fischofer
> Britestream Networks