W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2012

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

From: Cullen Jennings <fluffy@cisco.com>
Date: Tue, 14 Feb 2012 23:49:07 -0800
Cc: public-webrtc@w3.org
Message-Id: <9B8811A5-4CEE-4966-83D6-252DD7A0F5A2@cisco.com>
To: Randell Jesup <randell-ietf@jesup.org>

On Feb 13, 2012, at 9:43 , Randell Jesup wrote:

> 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.

Sounds good to me.
Received on Wednesday, 15 February 2012 07:49:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:27 UTC