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

[Michael Tuexen <[e-mail]>]

Hi Michael,

see my comments in-line.

Best regards
Michael
On Nov 3, 2011, at 2:12 AM, Michael Thornburgh wrote:

> comments on this draft:
> 
> section 3.2: reliable streams would be fairly simple to layer on top of any reliable and in-order datagram delivery service, not just SCTP's.
> 
> section 4.1: DCCP is not a good choice when any kind of reliability is desired. i've seen people on this list suggest that some kind of reliability/retransmission scheme can be layered on top of DCCP, and while that's certainly true, it's very un-optimal. DCCP already uses its own sequence numbers and acknowledgements to detect loss events and trigger congestion response, but that information is semantically hidden from higher-level users of DCCP. additional application-layer sequencing AND acknowledgement information must be implemented to 1) recover the original transmission order at the receiver (including waiting for gaps to be repaired, if in-order delivery is desired); and 2) duplicate application-layer loss detection at the sender (driven by the application-layer acks) must be performed to re-determine which segments were lost so they can be retransmitted. that sucks because, under the covers, DCCP already knew exactly which segments were lost and was in the best posit
> ion to trigger (fast-) retransmission if appropriate.
> 
> general comments on SCTP:
> 
> Matthew and i examined SCTP when we were designing MFP (the predecessor of RTMFP). in fact, if you look at the MFP protocol spec in the Internet Archive, you might notice a suspicious similarity to SCTP's chunk scheme.  :)
> 
> we rejected SCTP as inappropriate for real-time communication and our other use cases for several reasons. some of these have been at least partially addressed since our initial dismissal of SCTP in 2004 (in particular, DTLS in SCTP addresses the limitations of using TLS in SCTP [RFC3436], which at the time was the only way to "secure" SCTP messages; that mechanism meant that all secure messages/streams had to be fully reliable and in-order, which was unacceptable for real-time communication).
> 
> issues with SCTP that remain, and which i believe make it undesirable for WebRTC, include:
> 
>  o as you point out in section 5.3, running SCTP over DTLS, rather than DTLS over SCTP, is desired so that all SCTP fields, not just the user data, are secured. however, this configuration is currently not defined by IETF and would have to be specified.
> 
>  o DTLS and SCTP handshakes must be performed serially (no matter which order they happen in), which increases the number of round-trips necessary to establish communication.
That is correct. SCTP adds one RTT to whatever DTLS is requiring.
So when using SCTP/DTLS/UDP, DTLS needs 3 RTTs (including the initial
RTT required for the Cookie exchange).
When using DTLS/SCTP/UDP DTLS needs 2 RTTs (since there is no need for
the DTLS Cookie). I'm not sure how many RTTs ICE takes.
> 
>  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.
> 
>  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.
> 
>  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
http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-strrst-12
which is currently in IETF LC. It enables you to add streams on the fly.
> 
>  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?
> 
>  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.
> 
>  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 
> 
> specifying and implementing SCTP over DTLS over ICE over UDP is probably nearly as much work as specifying and implementing a new network protocol that actually solves the problems cleanly and holistically. having done that
It would be good to have a clean understanding of the problems. I agree with that.
> before a few times, i'm in favor of the clean holistic approach.  :)
> 
> -mike
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Randell Jesup
> Sent: Monday, October 31, 2011 8:18 PM
> 
> A new version of I-D, draft-jesup-rtcweb-data-01.txt has been successfully
> submitted by Randell Jesup and posted to the IETF repository.
> 
> [...]
> 
> http://www.ietf.org/id/draft-jesup-rtcweb-data-01.txt
> 
> [...]
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>