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?
http://www.cs.ucla.edu/~kohler/pubs/lai04efficiency.pdf
Eddie
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