Subject: [MMUSIC] Mirja Kühlewind's Discuss on draft-ietf-mmusic-sctp-sdp-23: (with DISCUSS)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Thu, 16 Feb 2017 03:20:33 -0800

Mirja Kühlewind has entered the following ballot position for
draft-ietf-mmusic-sctp-sdp-23: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Why is this using TCP/DTLS/SCTP instead of TCP/TLS/SCTP?

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 16 Feb 2017 06:36:16 -0800

Because it's always DTLS, just over a different transport.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Feb 2017 14:37:32 +0000

Hi Mirja,

...

> Why is this using TCP/DTLS/SCTP instead of TCP/TLS/SCTP?	

Because the way it is realized is by transporting SCTP on top of DTLS (as defined in draft-ietf-tsvwg-sctp-dtls-encaps) and transporting DTLS on top of TCP (defined in RFC 4571).

Regards.

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 16 Feb 2017 06:39:14 -0800

With that said, why are we registering TCP/DTLS/TCP at all? Is anyone
really going to use this without ICE?

-Ekr

On Thu, Feb 16, 2017 at 6:37 AM, Christer Holmberg <
[email-masked]> wrote:

> Because the way it is realized is by transporting SCTP on top of DTLS (as
> defined in draft-ietf-tsvwg-sctp-dtls-encaps) and transporting DTLS on
> top of TCP (defined in RFC 4571).
>
> Regards.
>
> Christer
>
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 16 Feb 2017 15:56:48 +0100

Hi,

> Am 16.02.2017 um 15:37 schrieb Christer Holmberg <[email-masked]>:
> 
> Hi Mirja,
> 
> ...
> 

I got this but DTLS is a mapping to use TLS with UDP because UDP is an unreliable datagram transport. If you use TCP, you should use TLS. And rfc4571 is not a mapping of DTLS to TCP.

Mirja

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Feb 2017 15:00:42 +0000

Hi,

>> Because the way it is realized is by transporting SCTP on top of DTLS (as defined in draft-ietf-tsvwg-sctp-dtls-encaps) and 
>> transporting DTLS on top of TCP (defined in RFC 4571).
>
> I got this but DTLS is a mapping to use TLS with UDP because UDP is an unreliable datagram transport. If you use TCP, you 
> should use TLS. And rfc4571 is not a mapping of DTLS to TCP.

The framing mechanism of RFC 4571 is used, with DTLS packets sent instead of RTP packets.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 16 Feb 2017 07:02:36 -0800

As Christer says. This design is optimized for making the media stack
simpler, which
using TLS here would not do.

-Ekr

On Thu, Feb 16, 2017 at 7:00 AM, Christer Holmberg <
[email-masked]> wrote:

> >> Because the way it is realized is by transporting SCTP on top of DTLS
> (as defined in draft-ietf-tsvwg-sctp-dtls-encaps) and
> > I got this but DTLS is a mapping to use TLS with UDP because UDP is an
> unreliable datagram transport. If you use TCP, you

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 16 Feb 2017 16:05:45 +0100

By making the transport stack overly complicated? That really gives me headache…

But let me get back the the other question you asked: Is the TCP variant really needed here? Is this implemented or are there any plans to implement that?

Mirja

> Am 16.02.2017 um 16:02 schrieb Eric Rescorla <[email-masked]>:
> 
> As Christer says. This design is optimized for making the media stack simpler, which
> On Thu, Feb 16, 2017 at 7:00 AM, Christer Holmberg <[email-masked]> wrote:
> Hi,
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 16 Feb 2017 07:12:47 -0800

> By making the transport stack overly complicated? That really gives me

It doesn't make the transport stack overly complicated. It makes it
modular. The way
that this works is that the transport system (typically ICE) provides a
generic
transport that appears to be a datagram transport, even if it's actually
TCP, and
so the thing on top of it just acts as it if were datagram. This is
necessary because
you may actually switch between TCP and UDP during the life of the
connection.

But let me get back the the other question you asked: Is the TCP variant
> really needed here? Is this implemented or are there any plans to implement
> that?
>

I think you misunderstood me. People absolutely intend to carry this data
over
TCP (it's basically the best scenario when you have (a) a centralized
service
and (b) a UDP-blocking Firewall). We in fact implement this with Firefox.
The only question is what should appear in the m= proto line.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Feb 2017 15:14:56 +0000

Hi,

>But let me get back the the other question you asked: Is the TCP variant really needed here? Is this implemented or are there any plans to implement that?

I'd have to double check whether e.g., the WebRTC data channel mandates support of TCP, but in any case draft-sctp-sdp recommends to only use it when UDP does not work.

Regards,

Christer

> simpler, which using TLS here would not do.
> 
> -Ekr
> 
> 
> 
> 
> >> Because the way it is realized is by transporting SCTP on top of 
> >> DTLS (as defined in draft-ietf-tsvwg-sctp-dtls-encaps) and transporting DTLS on top of TCP (defined in RFC 4571).
> >
> > I got this but DTLS is a mapping to use TLS with UDP because UDP is 
> > an unreliable datagram transport. If you use TCP, you should use TLS. And rfc4571 is not a mapping of DTLS to TCP.
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 16 Feb 2017 07:18:42 -0800

P.S. I am very familiar with the Firefox implementation of this, and I can
tell you
that it would be very painful to use TLS when TCP was used and DTLS when
UDP is used, and the modest network overhead for using DTLS is, IMO,
a better choice.

-Ekr

On Thu, Feb 16, 2017 at 7:12 AM, Eric Rescorla <[email-masked]> wrote:

>> DTLS (as defined in draft-ietf-tsvwg-sctp-dtls-encaps) and
>> an unreliable datagram transport. If you use TCP, you

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Feb 2017 15:24:35 +0000

Hi,

…

>The only question is what should appear in the m= proto line.

Even if nobody puts it in the m= line, I think it’s useful to keep it in the document, as it gives an overview how it’s realized etc.

It doesn’t cause any harm to keep it, and it’s “future proof” IF someone wants to use it without ICE at some point.

Regards,

Christer

> Am 16.02.2017 um 16:02 schrieb Eric Rescorla <[email-masked]<mailto:[email-masked]>>:
>
> On Thu, Feb 16, 2017 at 7:00 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
> Hi,
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 16 Feb 2017 12:39:42 -0500

Hi All,

I think a little bit of background will help here.

UDP/DTLS/SCTP and TCP/DTLS/SCTP are designed to work with ICE (RFC 5245).

In ICE environments, during the nomination process, end points go through
multiple candidate pairs, until the most preferred pair is found. During
this selection process, data can be sent as soon as the first working pair
is found, but the process still continues and candidate pairs can change
while data is sent. Furthermore, if end points roam, for instance when
mobile end point switches from mobile internet to wifi, end points will
initiate an ICE restart, which will trigger a new nomination process
between the new set of candidates and likely result in new nominated
candidiate pair. When these candidates change, the same DTLS association
continues to run, regardless whether it is running over udp or tcp
candidate pair. Because of this, ICE tcp requires using RFC 4571 framing
when sending data (https://tools.ietf.org/html/rfc6544#section-10.1).
Otherwise, if TLS were used, a new TLS or DTLS session would be required
every time candidate pair switches between tcp and udp candidates. In order
to simplify transition between different underlying transports, DTLS is
used for both udp and tcp candidates and TCP/DTLS/SCTP transport tag is
defined to differentiate it from other protocols.

As far as TCP/DTLS/SCTP transport tag is concerned, please note that ICE
end points are supposed to send a re-INVITE after nomination process is
completed with the selected candidate address in the m= line. So, if tcp
candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP transport
tag in the m= line. Also, any offers/answers after the ICE nomination is
complete, are supposed to send the currently selected candidate in the m=
line, which will also be TCP/DTLS/SCTP in case tcp candidate is selected.

I hope this addresses your concern and explains why TCP/DTLS/SCTP is
defined instead of TLS/SCTP.

Regards,
_____________
Roman Shpount

On Thu, Feb 16, 2017 at 10:24 AM, Christer Holmberg <
[email-masked]> wrote:

> Even if nobody puts it in the m= line, I think it’s useful to keep it in
> the document, as it gives an overview how it’s realized etc.
>
>
>
> It doesn’t cause any harm to keep it, and it’s “future proof” IF someone
> wants to use it without ICE at some point.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 17 Feb 2017 14:19:21 +0100

Hi Roman,

thanks a lot for the explanation. I talked to ekr yesterday during the telechat and already cleared my discuss. However, I think some more explanation about this ‚problem‘ explained below in the draft would be good as well.

I understood that TCP is rather the backup than a preferred solution but it wasn’t clear to me at the beginning how dynamically the situation can realistically change. I think it would be still good to note more explicitly in the draft that UDP should be the prefer transport (especially if e.g. ICE is not used) and that both approaches are not equally good. Also if you use SCTP over TCP you have two congestion control loops. While the transmission over TCP will appear loss-free for the SCTP stack, due to TCP retransmissions SCTP will see higher delay variations that also influence the transmission behavior and may slow down SCTP unnecessarily. I think that might be also wot noticing.

Regarding the m= line (and I’m by far not expert here, so excuse me if that doesn't make sense), I guess for the ICE case you could also just use DTLS/SCTP, no? Wouldn't that resolve the oddity that you announce one thing and use another? And then you can maybe have an additional tag for the transport used for the non-ICE cases…? Mainly wondering if there is maybe a clearer solution here?

Mirja

> Am 16.02.2017 um 18:39 schrieb Roman Shpount <[email-masked]>:
> 
> Hi All,
> 
> In ICE environments, during the nomination process, end points go through multiple candidate pairs, until the most preferred pair is found. During this selection process, data can be sent as soon as the first working pair is found, but the process still continues and candidate pairs can change while data is sent. Furthermore, if end points roam, for instance when mobile end point switches from mobile internet to wifi, end points will initiate an ICE restart, which will trigger a new nomination process between the new set of candidates and likely result in new nominated candidiate pair. When these candidates change, the same DTLS association continues to run, regardless whether it is running over udp or tcp candidate pair. Because of this, ICE tcp requires using RFC 4571 framing when sending data (https://tools.ietf.org/html/rfc6544#section-10.1). Otherwise, if TLS were used, a new TLS or DTLS session would be required every time candidate pair switches between tcp and udp candidates. In order to simplify transition between different underlying transports, DTLS is used for both udp and tcp candidates and TCP/DTLS/SCTP transport tag is defined to differentiate it from other protocols.
> 
> As far as TCP/DTLS/SCTP transport tag is concerned, please note that ICE end points are supposed to send a re-INVITE after nomination process is completed with the selected candidate address in the m= line. So, if tcp candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP transport tag in the m= line. Also, any offers/answers after the ICE nomination is complete, are supposed to send the currently selected candidate in the m= line, which will also be TCP/DTLS/SCTP in case tcp candidate is selected.
> 
> I hope this addresses your concern and explains why TCP/DTLS/SCTP is defined instead of TLS/SCTP.
> 
> Regards,
> _____________
> Roman Shpount
> 
> On Thu, Feb 16, 2017 at 10:24 AM, Christer Holmberg <[email-masked]> wrote:
> Hi,
> 
>  
> 
> …
> 
>  
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Feb 2017 13:46:13 +0000

Hi,

>Regarding the m= line (and I’m by far not expert here, so excuse me if that doesn't make sense), I guess for the ICE case you
>could also just use DTLS/SCTP, no? Wouldn't that resolve the oddity that you announce one thing and use another? And then 
>you can maybe have an additional tag for the transport used for the non-ICE cases…? Mainly wondering if there is maybe a clearer solution here?

That has been discussed, but the decision was to not do it within this draft.

There have been generic discussions about defining "ICE tags". But, that would be done as a separate task, and would cover other transports than this.

Regards,

Christer

> > As Christer says. This design is optimized for making the media 
> > stack simpler, which using TLS here would not do.
> >
> > -Ekr
> >
> >
> >
> >
> > > I got this but DTLS is a mapping to use TLS with UDP because UDP 
> > > is an unreliable datagram transport. If you use TCP, you should use TLS. And rfc4571 is not a mapping of DTLS to TCP.
> >

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Sun, 19 Feb 2017 11:04:50 +0100

Hi Roman,

thanks again. And again I think more text is needed in the draft.

Mirja

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Sun, 19 Feb 2017 15:02:06 +0100

Hi again,

actually I have one more mostly editorial comment. I would probably recommend to not just say that the framing of rfc 4571 is used but instead specify the framing in this draft (where you oft course still can say that the framing is similar to 4571). The reason is that other than the framing format itself the rest of rfc 4571 is not relevant because you use SCTP on top.

And again, it would probably also be good to talk a little more about implication when you use SCTP on top of TCP, mostly regarding the two layers of congestion control that you get.

Mirja

> Am 19.02.2017 um 11:04 schrieb Mirja Kuehlewind (IETF) <[email-masked]>:
> 
> Hi Roman,
>

---

From: Roman Shpount <[email-masked]>
Date: Sun, 19 Feb 2017 11:46:18 -0500

Mirja,

As I have mentioned before, protocols described in this draft are intended
to work with ICE. The framing for ICE TCP is defined in RFC 6544 (
https://tools.ietf.org/html/rfc6544#section-10.1) and this document
explicitly specifies RFC 4571 framing. The same document describes why the
same framing must be used for RTP, STUN or non-RTP media, such as DTLS
packets carrying SCTP. Current draft simply restates the framing
requirement from RFC 6544 and defines a protocol that will satisfy RFC 6544
requirements. Because of this, and because the framing must be identical
for all the protocols that use ICE TCP, we cannot re-define the framing in
this draft. The definition must stay in the same place, so that any changes
made to framing are verified to be compatible with other protocols which
are using it and will propagate to these protocols as well.

We are happy to add any informational content to describe the implications
of running SCTP on top of TCP, but we would prefer not to redefine how ICE
operates (including framing used for ICE TCP) in this draft. I think,
generic ICE procedures belong in ICE related drafts.

Regards,

_____________
Roman Shpount

On Sun, Feb 19, 2017 at 9:02 AM, Mirja Kuehlewind (IETF) <
[email-masked]> wrote:

> Hi again,
>
> actually I have one more mostly editorial comment. I would probably
> recommend to not just say that the framing of rfc 4571 is used but instead
> specify the framing in this draft (where you oft course still can say that
> the framing is similar to 4571). The reason is that other than the framing
> format itself the rest of rfc 4571 is not relevant because you use SCTP on
> top.
>
> And again, it would probably also be good to talk a little more about
> implication when you use SCTP on top of TCP, mostly regarding the two
> layers of congestion control that you get.
>
> Mirja
>
>
>
>
> >> Am 16.02.2017 um 18:39 schrieb Roman Shpount <[email-masked]
> >:
> >>
> >> Hi All,
> >>
> >> In ICE environments, during the nomination process, end points go
> through multiple candidate pairs, until the most preferred pair is found.
> During this selection process, data can be sent as soon as the first
> working pair is found, but the process still continues and candidate pairs
> can change while data is sent. Furthermore, if end points roam, for
> instance when mobile end point switches from mobile internet to wifi, end
> points will initiate an ICE restart, which will trigger a new nomination
> process between the new set of candidates and likely result in new
> nominated candidiate pair. When these candidates change, the same DTLS
> association continues to run, regardless whether it is running over udp or
> tcp candidate pair. Because of this, ICE tcp requires using RFC 4571
> framing when sending data (https://tools.ietf.org/html/
> rfc6544#section-10.1). Otherwise, if TLS were used, a new TLS or DTLS
> session would be required every time candidate pair switches between tcp
> and udp candidates. In order to simplify transition between different
> underlying transports, DTLS is used for both udp and tcp candidates and
> TCP/DTLS/SCTP transport tag is defined to differentiate it from other
> protocols.
> >>
> >> As far as TCP/DTLS/SCTP transport tag is concerned, please note that
> ICE end points are supposed to send a re-INVITE after nomination process is
> >> Even if nobody puts it in the m= line, I think it’s useful to keep it
> in the document, as it gives an overview how it’s realized etc.
> >>
> >>
> >>
> >> It doesn’t cause any harm to keep it, and it’s “future proof” IF
> someone wants to use it without ICE at some point.
> >>
> >>
> >>
> >> Regards,
> >>
> >>
> >>
> >> Christer
> >>
> >>
> >>
> >>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 20 Feb 2017 10:49:06 +0100

> 
> On Feb 19, 2017, at 5:46 PM, Roman Shpount <[email-masked]> wrote:
> 

[...]

> We are happy to add any informational content to describe the implications of running SCTP on top of TCP, but we would prefer not to redefine how ICE operates (including framing used for ICE TCP) in this draft. I think, generic ICE procedures belong in ICE related drafts.

I agree in principle; this draft is about signaling, not the media stream itself. But Mirja's comments suggest that the referenced specs may not fully describe how the stream works. Is there anything else we could reference (e.g.  RTCWEB data-channel or transports drafts) that would help clarify?  (Please feel free to argue that the referenced docs do in fact describe things sufficiently for the purposes of this draft, if you believe that to be true :-) )

Thanks,

Ben.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 20 Feb 2017 12:05:37 +0100

Hi Roman,

I think the problem is that someone who would not want to use ICE would not look at RFC6544. This means at least this part of RFC6544 is missing as general guidance in this draft:

"For media streams that are not RTP-based and do not normally use 
   RFC4571, the agent treats the media stream as a byte stream and assumes
   that it has its own framing of some sort, if needed.  It then takes
   an arbitrary number of bytes from the byte stream and places that as
   a payload in the RFC 4571 frames, including the length."

Usually duplicating text is not recommendable. However it this case it might be the easiest solution if you want to keep the document generally applicable even if you don’t use ICE. 

Also I’m not sure if the ICE part is fully specified. In your previously mail you wrote

"As far as TCP/DTLS/SCTP transport tag is concerned, please note that ICE end points are supposed to send a re-INVITE after nomination process is completed with the selected candidate address in the m= line. So, if tcp candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP transport tag in the m= line. Also, any offers/answers after the ICE nomination is complete, are supposed to send the currently selected candidate in the m= line, which will also be TCP/DTLS/SCTP in case tcp candidate is selected.“

From what I understood from ekr, you might not in any case send an re-invite; but maybe I understood this wrongly. I guess that could also be further explained in the draft.

Mirja

> Am 20.02.2017 um 10:49 schrieb Ben Campbell <[email-masked]>:
> 
>>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 Feb 2017 13:06:00 +0000

Hi,

...

>Also I¹m not sure if the ICE part is fully specified. In your previously
>mail you wrote
>
>"As far as TCP/DTLS/SCTP transport tag is concerned, please note that ICE
>candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP
>transport tag in the m= line. Also, any offers/answers after the ICE
>nomination is complete, are supposed to send the currently selected
>candidate in the m= line, which will also be TCP/DTLS/SCTP in case tcp
>candidate is selected.³
>
>From what I understood from ekr, you might not in any case send an
>re-invite; but maybe I understood this wrongly. I guess that could also
>be further explained in the draft.

Ekr was talking about the specific re-INVITE that is sent directly after
ICE nomination. *Other* re-INVITEs can always be sent during the session.
But, that is not specific to this draft.

Regards,

Christer