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

[Michael Tüxen <[e-mail]>]

On Nov 3, 2011, at 4:41 PM, Randell Jesup wrote:

> On 11/3/2011 9:09 AM, Magnus Westerlund wrote:
>> When it comes to the actual usage of either of IP/UDP/SCTP/DTLS and
>> IP/UDP/DTLS/SCTP we have the same two dependencies on other WGs.
>> 
>> First we need a SCTP over foo document, which is TSVWG. The SCTP over
>> UDP is already an WG document and making some progress. For SCTP over
>> DTLS there would be need for a new document, or possibly get that
>> defined in the same as SCTP over UDP directly.
>> 
>> Secondly if one uses SDP one needs a definition of how one expresses
>> this on the media description line. That includes the "proto" identifier
>> itself and any additional information, like direction for establishing
>> the connection which would be similar to what COMEDIA defines for TCP
>> (RFC 4145).
> 
> We probably need to do these in any case (SCTP or not).
> 
>>> From a time perspective IP/UDP/SCTP/DTLS is the quicker road as the SCTP
>> over UDP is already in progress and DTLS over SCTP is defined.
> 
> Right, but that also means we'd need to define reliable stream-like layers on top of DTLS-over-SCTP, deal with large message fragmentation, etc.  Perhaps someone with more DTLS-over-SCTP knowledge (Michael, Randy) could detail what the impact would be.  (I'll also start reviewing the DTLS-over-SCTP draft.)
If the upper layer knows that you use stream n in "stream line mode", you can just
ignore the message framing. Pretty simple. No changes needed. Runs over SCTP or DTLS.

If you need large messages with message boundaries, it can be added to SCTP.
It should be not too hard. Randy and myself will look into it... However, 
to allow multiplexing with having more than one message being sent concurrently,
a new chunk is necessary.

Just one note: DTLS-over-SCTP is an RFC and you can find a patch for OpenSSL at
http://sctp.fh-muenster.de/dtls-patches.html

>> So what exist here is really:
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/
>> https://datatracker.ietf.org/doc/rfc6083/ (DTLS over SCTP)
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-udp-encaps/
>> 
>> 
>>> 
>>> In response I have to say: put a protocol proposal on the table or
>>> gather a group to do so, and do so ASAP, because if we don't get an
>>> alternative, it *will* be either SCTP/DTLS/(ICE/UDP) or
>>> pseudo-TCP/DTLS/(ICE/UDP), and I don't know what we'd do for the
>>> unreliable congestion-controlled channels (maybe DCCP).
>> 
>> Personally view:
>> 
>> I think the choice will be between either
>> 
>> DTLS/SCTP/UDP or SCTP/DTLS/UDP
>> 
>> and
>> 
>> TCP/UDP + DCCP/UDP
> 
> I agree that this is the fundamental choice, barring some surprise. There is one other option, though I would vote against it and I doubt anyone really wants it: drop internal data streams and require use of websockets for data (and that means no unreliable streams, which severely crimps real-time data use).
> 
> 
> Sometimes it seems like it would be easier to rubber-stamp (document if you prefer) an existing protocol design done outside the standards process than to develop one inside of it, which is a problem, but not one we'll solve here.
> 
> Realize that if we don't find a solution that works within the standards process, the vendors in question will be forced to implement something that gives the desired functionality in the timeframe required, and then it would turn into a case of a defacto standard in need of documentation.  Obviously I think all here would prefer to avoid that scenario.
> 
>>> If you do put forward a proposal, do you really believe it can be
>>> done, standardized, agreed to and implemented in the timeframe
>>> required? Specifying SCTP/DTLS seems relatively straightforward
>>> compared to standardizing a new protocol...  The timeframe for this
>>> is quite constrained already; one of the strongest arguments against
>>> SCTP would also be timeframe, except that SCTP gives us
>>> congestion-controlled unreliable data, which pseudo-TCP-over-DTLS
>>> doesn't - we'd have to use yet another unspecified mechanism for
>>> congestion control of the unreliable data channels.
>>> 
>> 
>> I personally don't think think this can be done in short time frames
>> within the IETF. The reason is that IETF will have to do the following
>> to get this going and in the end produce an RFC:
> 
> [snip 16 steps]
> 
>> Just the required process steps in the above is on the order of 3
>> months. My guess is that even if interest in this holds it is 3-4 years
>> before IETF can conclude on a new transport protocol.
> 
> Even getting to the point where we have a complete enough draft within the IETF is probably a minimum of 2 years (witness OPUS/codec).
> 
> 
> -- 
> Randell Jesup
> [e-mail]
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>