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

[Magnus Westerlund <[e-mail]>]

On 2011-11-03 05:51, Randell Jesup wrote:
> On 11/2/2011 9:12 PM, Michael Thornburgh wrote:

>> 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.
> 
> 
> Ok - though conceptually SCTP should be able to run over anything 
> presenting a UDP-like interface.   There are some fallouts, like no 
> multi-homing.  Can some others here (Magnus?) with better
> understanding of the exact RFC requirements state if it would be
> acceptable to reference a SCTP-over-DTLS draft, which should be
> fairly straightforward to create and move forward?

It is fine for this WG to request publication of a document with
normative references to internet drafts. What really happens is two
things. First we WG chairs + AD needs to determine if it is reasonable
to request publication without the normative reference being ready. That
depends on how clean the separation is. Secondly even if IESG approves
our document, the RFC can't be published until that draft also is
approved and ready to be published. This is fairly common and if you
look at the RFC-editors home page they have this clusters for documents
that await publication due to the normative reference not being ready.

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

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

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


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

1. Write a Charter proposal for a WG in TSV.
2. Have a BOF on the need for creating a new transport protocol
3. Take in all the additional views from other proponents of transport
protocol evolution. I think that means combing Structure Streams with
SCTP + DCCP to build a new swiss army knife of a protocol
4. Agree on the new charter
5. Send it to IESG for approval
6. Have the IETF last call and deal with the comments.
7. Finally having a WG
8. Do a requirements phase
9. Design the new protocol in a committee
10. Have the new protocol receive wide review from OPS, Sec etc.
11. Improve spec by having N meeting cycles go by.
12. WG last call
13. IETF last call
14. IESG approval
15. RFC editor
16. RFC publication

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.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------