W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2011

Re: Proposed data channel API

From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 11 Nov 2011 10:52:06 -0800
Message-ID: <CABcZeBNWtmfDRHdV1utuzn1otMzPmj3wz8Ca2te5_T1YO161xw@mail.gmail.com>
To: Randell Jesup <randell-ietf@jesup.org>
Cc: public-webrtc@w3.org
On Fri, Nov 11, 2011 at 10:36 AM, Randell Jesup <randell-ietf@jesup.org> wrote:
> On 11/11/2011 1:07 PM, Vincent Scheib wrote:

> In unreliable mode, I would strongly disagree with that.  Out-of-order
> packets should be flagged to the application (if by no other means than by
> providing a sequence #, or by the application being responsible for adding
> sequence numbers to its own data packets), but the application should decide
> if they're important or processable.  I've had connections *at work* that
> could get >1% OOO packets on RTP, for *years*, and was running videophone
> calls from this network all the time.  (Some sort of weird
> router-and-bonded-T1 issue the provider never resolved.)
> If the app wants to discard them, fine.  I would be *ok* (though mildly
> concerned) with an app asking the system to discard them for it.

A related question is retransmitted packets.

This is actually a slightly more subtle point than it sounds because suppression
of retransmitted packets at layer N implies either (a) dropping some out of
order packets or (b) potentially unbounded memory growth to remember which
packets have been received and which have not. So, if layer N+1 wants
a guarantee of no retransmissions it generally implies that some really out of
order packets get dropped.

Received on Friday, 11 November 2011 18:53:38 UTC

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