Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt

Michael Thornburgh <> Fri, 11 November 2011 19:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4E08F21F8560 for <>; Fri, 11 Nov 2011 11:53:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id THQ-t1JdVqA8 for <>; Fri, 11 Nov 2011 11:53:36 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A5D1D21F84AF for <>; Fri, 11 Nov 2011 11:53:35 -0800 (PST)
Received: from ([]) by ([]) with SMTP ID; Fri, 11 Nov 2011 11:53:35 PST
Received: from ( []) by (8.12.10/8.12.10) with ESMTP id pABJrNQB029723; Fri, 11 Nov 2011 11:53:25 -0800 (PST)
Received: from ( []) by (8.12.10/8.12.10) with ESMTP id pABJrN5R011352; Fri, 11 Nov 2011 11:53:23 -0800 (PST)
Received: from ([]) by ([]) with mapi; Fri, 11 Nov 2011 11:53:22 -0800
From: Michael Thornburgh <>
To: Michael Tuexen <>, "" <>
Date: Fri, 11 Nov 2011 11:52:32 -0800
Thread-Topic: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt
Thread-Index: AcygdFGNq3bifgSfQ7u1JN6yBGevMAAMaBuw
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Nov 2011 19:53:37 -0000

hi Michael. my comments also inline.

> -----Original Message-----
> From: Michael Tuexen [] 
> Sent: Friday, November 11, 2011 5:16 AM
> Subject: Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt
> Hi Michael,
> see my comments in-line.
> Best regards
> Michael
> On Nov 3, 2011, at 2:12 AM, Michael Thornburgh wrote:
> >  o (most important for real-time communication): each user data fragment/chunk is assigned an SCTP Transmission Sequence Number (TSN) at the time of first transmission. that means even if your SCTP implementation supported stream prioritization somehow, the priority decision is only made at first transmission time. since there's just one TSN space and the Gap Ack structure only talks about TSNs, it's undesirable for gaps to persist (else the Gap Ack structure will continue to grow as more losses naturally happen). therefore it's desirable to repair gaps as quickly as possible. this may inappropriately increase the priority of a low priority fragment/chunk/stream during periods of congestion, which is exactly when priority matters (this is a "priority inversion").
> What might help is that messages have priorities and the sender is allowed to abandon messages
> with low priorities in case of congestion (timer based retransmissions). Something which is supported by PR-SCTP.

sure. but the problem here is the low priority stream is likely to be one that needs full reliability (like a bulk data transfer that you want to use "background" bandwidth but still eventually get delivered). in that case you don't want the sender to abandon the low priority message, and that's what leads to the priority inversion.

> >  o (second most important for real-time communication): there's only one receive window advertisement for all of the streams, rather than one receive window per stream. this means there's no per-stream flow control. so if you're receiving (for example) a bulk file transfer and real-time player position updates and text chat messages, and you need to suspend the file transfer stream for a time, that means you must also suspend the player position updates and text chat messages. unless you spin up an entirely separate SCTP for each flow control domain, which is lame and defeats the purpose of stream multiplexing.
> You can use priorities tied to streams at the sender side.

priority doesn't solve the problem at all. the issue is that if the receiver needs to stop accepting data on one stream, the only indication of reverse pressure to the sender is the association-wide receive window advertisement. the only in-protocol flow control is association-wide. the only solution is to not have the receiver suspend reading any stream and to use application-layer flow control to signal the sender to stop sending data on one stream or another.

> >  o SCTP specifies the maximum number of streams in each direction at association startup. web applications may not know the number of streams needed up front; in fact, the number of streams needed in any real-world non-SS7 data application is very likely to evolve over the lifetime of that application, naturally increasing and decreasing.
> You don't need a lot of resources for the receive side of a stream. So you could either negotiate a number
> large enough or use the extension
> which is currently in IETF LC. It enables you to add streams on the fly.

ok. i'm glad someone thought of that.

> >  o the semantics of unordered messages are confusing and not a good map to WebRTC. they are semantically equivalent to an entirely separate stream loosely associated to the ordered stream of the same number. there's no way to tell (without application layer sequencing) if an unordered message has been lost/abandoned by the sender. at the protocol level, TSNs can be used to recover the queuing order of received unordered messages, but the TSNs are semantically disconnected from the SCTP user. recovering the original queuing order over a short reorder/reassembly window period is desirable in some real-time applications.
> The concept of PR-SCTP is that the receiver can handle this. Since the sender decided that the sequencing
> is not important, why should be receiver care?

my main point was that, specifically in the case of PR-SCTP, since unordered messages don't have a stream sequence number there's no way to tell at the receiver if one (or more) has been abandoned. gaps in the ordered message space can be detected.

> >  o an SCTP receiver should be able to choose to receive stream messages in originally-queued order or as-received-on-the-network order on a per-stream basis, and be able to recover the original queuing order to whatever extent desired (potentially limited by real-time constraints) when receiving in network order. SCTP's unordered message semantics are designed for "out-of-band" messages, and are not a good fit for general "real-time" data. transmission order should be determined by the sender, reception order should be determined by the receiver.
> It is a sender side thing. If the sender requires in-sequence delivery, you want the receiver to ignore
> this requirement? If there is not sequencing constraint, the sender should not send it ordered.

it's natural to use unordered messages for real-time data, since they can be delivered to the user as soon as they arrive even if there are gaps. however, in exactly these real-time scenarios, it's still often useful to know the original queuing order of the messages, and to allow the receiver to partially recover the original queuing order in, for example, a jitter/reorder buffer. this can be accomplished with application-layer sequence numbers, but it seems silly to have to duplicate existing protocol-level functionality (see my point about flow control above).

> >  o the stream sequence number being only 16 bits limits the maximum message rate through high delay networks where message gaps can be reliably detected at the receiver, when the sender uses limited-reliability, to 32767 messages/RTT. that sounds large, but could be easily reached even today in moderately high bandwidth*delay paths if messages are small.
> I don't understand this limitation. The is a 32-bit sequence number space (TSNs) which limits you 2**31 - 1
> DATA chunks being in flight (as indicated by the last sentence of Section 6.1 of RFC 4960),
> but the 16-bit per stream sequence numbering (SSNs) does not have this restriction.
> The receiver will recover the sequencing based on SSN and TSN. At least this is 

this is only a problem with PR-SCTP. if stream sequence numbers can be abandoned, then there's ambiguity in the stream sequence number space when you receive a FORWARD TSN chunk if there were more than 32768 stream sequence numbers in flight.