Re: Data API: what is agreed, what is open - buffering

On 2/13/2012 11:02 AM, Cullen Jennings wrote:
> On Feb 13, 2012, at 6:08 AM, Stefan Hakansson LK wrote:
>
>>>
>>>> * The API should allow the application to check if data is being
>>>> buffered (so that it can adjust the send rate)
>>> uh - I have no idea what this even means. Of course it is buffered -
>>> it's a transport. Need to know more.
>> The app should be able to determine if more and more data is being buffered locally - that is a sign that the app is trying to send more data than the channel can carry.
> So the user land SCTP is going to be buffering, and at the same time dropping out UDP packets which the kernel will be buffering then there is the nic cards, routers, etc that all buffer.

The assumption is that we're talking application-level (i.e. 
congestion-control-defined) buffering.  I'm ignoring kernel-level 
buffering, and assuming that data sent to the UDP layer goes out "real 
soon now", even if it ends up being buffered or dropped in the network.  
The point here is to give the app feedback into how much/how quickly the 
data it sends gets out.

> What makes sense to me is a way to find the current depth of the SCTP buffer. Trying to figure out how much UDP data the kernel/nic had buffered seems like it could get hard but it could be a large number so it perhaps you have to know this to make things really work. Given some of the SCTP streams may be reliable, some unreliable, and there are multiple at the same time, It's not clear to me if you want to report just the buffered data for single SCTP stream or for the aggregate buffering across the SCTP association.

I think we want the buffersize for SCTP data, preferably for the 
particular stream (since each stream could have a differing level, 
dependent on reliability, random loss and stream 'priority')  and the 
stream is what the application will care about.

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Monday, 13 February 2012 17:45:07 UTC