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

[Randell Jesup <[e-mail]>]

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.)

> 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]