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

Re: Proposed data channel API

From: Justin Uberti <juberti@google.com>
Date: Sat, 12 Nov 2011 01:25:45 -0500
Message-ID: <CAOJ7v-1ckUNzdJQVHVP-kOTA8KfkcDWhbOZ7qDQMfWN3_YoW1w@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Randell Jesup <randell-ietf@jesup.org>, public-webrtc@w3.org
On Fri, Nov 11, 2011 at 1:52 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> 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.
>
>
Right, I imagine we would maintain some sort of window like SRTP where we
discard anything that falls outside of the window.
Received on Saturday, 12 November 2011 06:43:33 UTC

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