Subject: [clue] Draft new version: draft-holmberg-clue-data-channel-04

From: Christer Holmberg <[email-masked]>
Date: Thu, 13 Mar 2014 11:04:30 +0000

Hi,

Based on the discussions in London, I've submitted a new version (-04) of draft-holmberg-clue-data-channel.

The draft now assumes that we will use the WebRTC Data Channel (that's what it's called at the moment...), and DCEP. There is a note regarding the usage of Richard's draft, depending on the progress of the draft in MMUSIC.

In London we also agreed to WG adopt the draft, so this is the version I intend to submit as draft-ietf-clue-00, as soon as the chairs give me a go ahead :)

Thanks to everyone that have given input and comments so far - both on the list and in the meetings! :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Mar 2014 12:29:21 -0400

Christer,

This is really starting to shape up well. I do have comments on this 
version, but IMO they don't impact adoption - they can be addressed 
either before or after. I want to talk to mary before initiating adoption.

Section 3.2:

I think this section could be weakened, to make DCEP the mechanism of 
last resort to establish the CLUE data channel, while *allowing* some 
other (currently unspecified) mechanism to preempt that.

For instance:

    In the absence of some other mechanism, a CLUE entity MUST use the
    Data Channel Establishment Protocol (DCEP) [I-D.ietf-rtcweb-
    data-channel], in order to open a CLUE Data Channel.

    (This document does not define any other mechanism for establishing
    the CLUE channel, but one may be defined in the future.)

Section 3.3.2:

    The usage of SCTP for the CLUE Data Channel ensures reliable
    transport of CLUE protocol [I-D.presta-clue-protocol] messages.

    NOTE: [I-D.ietf-rtcweb-data-channel] requires the support of the
    partial reliability extension defined in [RFC3758].  This is not
    needed for a CLUE Data Channel, as messages are required to always be
    sent reliably.  [I-D.ietf-rtcweb-data-channel] also mandates support
    of the limited retransmission policy defined in
    [I-D.tuexen-tsvwg-sctp-prpolicies].

I think you need to be stronger here, and say that the parital 
reliability and limited retransmission policies MUST NOT be used.

And when using DCEP, this is governed by the DCEP OPEN message 
parameters. I when opening the CLUE channel the Channel Type MUST be 
DATA_CHANNEL_RELIABLE. But this probably belongs in section 4.1.

Section 4.1:

I wonder if we want to include a version number in the protool name, 
just as another level of future-proofing.

Section 4.2:

This is a little vague about which of the pair of streams is reset.

Section 7.2 of draft-jesup-rtcweb-data-protocol-04 says more about this. 
(Though it has some editorial issues.) ISTM that should either be 
referenced or copied here.

Section 4.3:

This section (and maybe others) refers to "the offerer". I don't think 
this is very clear. I think it would be helpful to define a new term 
(role) (e.g. Master) that identifies which end of the session is 
responsible for maintaining the association. It could be the end that 
sends the first offer that mentions the SCTP m-line in the clue group, 
or it could be more complicated. But regardless, it is defined in one 
place, and other places just reference that term, rather than something 
confusing like "offerer".

Section 5.2:

Where did you get this proto value???

According to draft-ietf-mmusic-sctp-sdp-06 it should be DTLS/SCTP.

Section 5.4:

    In an offer, the offerer MUST NOT insert more than one "m=" line
    describing an SCTPoDTLS association to be used to realize a CLUE Data
    Channel.

I think this is a little strong. I think we can say that the clue group 
must contain exactly one DTLS/SCTP m-line. Potentially there could be 
others that aren't in the clue group - they aren't our concern.

I think it would be helpful to discuss the use of a=setup and 
a=connection here. (and in 5.5.) These may also provide a basis for 
defining which end takes future responsibility for maintaining the 
association.

(BUT, these also apply to DTLS. draft-ietf-mmusic-sdp-mux-attributes-01 
says that these attributes must be the same across a bundle. This 
constrains things.)

	Thanks,
	Paul

On 3/13/14 7:04 AM, Christer Holmberg wrote:
> Hi,
>
> Based on the discussions in London, I’ve submitted a new version (-04)
> of draft-holmberg-clue-data-channel.
>
> The draft now assumes that we will use the WebRTC Data Channel (that’s
> what it’s called at the moment…), and DCEP. There is a note regarding
> the usage of Richard’s draft, depending on the progress of the draft in
> MMUSIC.
>
> In London we also agreed to WG adopt the draft, so this is the version I
> intend to submit as draft-ietf-clue-00, as soon as the chairs give me a
> go ahead :)
>
> Thanks to everyone that have given input and comments so far – both on
> the list and in the meetings! J
>
> Regards,
>
> Christer
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 13 Mar 2014 18:25:26 +0000

Hi Paul,

>    the CLUE channel, but one may be defined in the future.)

Ok.

-----------------

> reliability and limited retransmission policies MUST NOT be used.

Ok.

-----------------

> DATA_CHANNEL_RELIABLE. But this probably belongs in section 4.1.

Ok.

-----------------

> just as another level of future-proofing.

I can add it as an open issue.

-----------------

> referenced or copied here.

Ok.

-----------------

> confusing like "offerer".

Well, comedia also talks about the offer and the answerer, for TCP.

HAVING SAID THAT, I actually think this section belongs in the sctp-sdp draft. Because, as there may be many data channels, with different protocols, running on the SCTP association, there needs to be a common way for handling SCTP association failures.

-----------------

> According to draft-ietf-mmusic-sctp-sdp-06 it should be DTLS/SCTP.

Sorry, copy/paste error. I'll fix it :)

-----------------

> others that aren't in the clue group - they aren't our concern.

What do you mean by "clue group"? Do you mean BUNDLE group?

Note that I am NOT saying one can only use one DTLS/SCTP m- line. I am saying that one can use one m- line for CLUE Data Channel purpose. 

But, when thinking about it, I don't think we need to say that. We already say that one can only use one CLUE Data Channel per CLUE session, so...

-----------------

>defining which end takes future responsibility for maintaining the

I actually think that both 5.4 and 5.5 belong to the sctp-sdp draft. There needs to be a common way for establishing the SCTPoDTLS assocation, and there is nothing CLUE specific in the text.

(Then, if we adopt Richard's draft at some point, we obviously need to describe the CLUE specific offer/answer procedures associated with that mechanism.)

Thanks for the comments!

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Mar 2014 11:31:24 -0400

I've trimmed out all the parts where there is nothing more to say.

WFM

Does it do so when referring to some past o/a? I know it talks about the 
*current* offerer and answerer. That is fine. Its when talking about the 
roles from some past O/A cycle (especially when it might not even be the 
prior one) that it gets confusing.

> HAVING SAID THAT, I actually think this section belongs in the sctp-sdp draft. Because, as there may be many data channels, with different protocols, running on the SCTP association, there needs to…

Perhaps it does. But I think we need to have it in our stuff until it 
shows up in something we can reference. (There may be difficulty 
convincing others that this belongs in the sctp-sdp draft.)

I mean the m-lines included in the a=group:clue (defined in the latest 
version of the signaling draft).

> But, when thinking about it, I don't think we need to say that. We already say that one can only use one CLUE Data Channel per CLUE session, so...

But if there is more than one DTLS/SCTP m-line, then we do need to 
specify which one will be used for the clue channel.

Agree. But if we somehow can't get it put in there, then I think we 
should include it in our stuff.

> (Then, if we adopt Richard's draft at some point, we obviously need to describe the CLUE specific offer/answer procedures associated with that mechanism.)

Right.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Mar 2014 16:38:46 +0000

Hi,

> prior one) that it gets confusing.

My understanding is that you are considered the offerer until another the other peer sends an offer. It may not be very clear in the spec, though.

>> HAVING SAID THAT, I actually think this section belongs in the sctp-sdp draft. Because, as there may be many data channels, with different protocols, running 
>> on the SCTP association, there needs to be a common way for handling SCTP association failures.
>

We'll see - so far nobody has said that it does NOT belong there :)

-----------------

> version of the signaling draft).

Aaah... ok... I didn't think of that.

> specify which one will be used for the clue channel.

I can add text regarding the group.

-----------------

> Agree. But if we somehow can't get it put in there, then I think we should include it in our stuff.

Section 6 of the sctp-sdp draft does talk about the setup and connection attributes (it basically referes to TCP), so we can reference that.

6.  The Setup and Connection Attributes and Association Management

   The use of the 'setup' and 'connection' attributes in the context of
   an SCTP association is identical to the use of these attributes in
   the context of a TCP connection.  That is, SCTP endpoints MUST follow
   the rules in Sections 4 and 5 of RFC 4145 [RFC4145] when it comes to
   the use of the 'setup' and 'connection' attributes in offer/answer
   [RFC3264] exchanges.

   The management of an SCTP association is identical to the management
   of a TCP connection.  That is, SCTP endpoints MUST follow the rules
   in Section 6 of RFC 4145 [RFC4145] to manage SCTP associations.
   Whether to use the SCTP ordered or unordered delivery service is up
   to the applications using the SCTP association.

If we have comments on that text we should take it to MMUSIC :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Mar 2014 13:05:50 -0400

> My understanding is that you are considered the offerer until another the other peer sends an offer. It may not be very clear in the spec, though.

I don't know, though that seems plausible.

But my understanding was that what you were talking about is the sender 
of the offer that first introduced the sctp m-line. And that this role 
wouldn't be changed by future offers coming in the other direction.

Maybe that isn't what you meant. But if so then again it seems unclear 
to me.

Actually, I think the most difficult issues have to do with this and 
bundling. ISTM the implications need to be thought through, and then 
there *might* be a need to write something somewhere - not sure where.

Here are a couple of issues that come to mind:

- a bundle is created with some DTLS/RTP m-lines.
   Later, there is desire to add the DTLS/SCTP to the bundle.
   This will be a *new* SCTP association, but using the
   *existing* DTLS connection. So what is the a=connection
   attribute set to? And must it be the same for all the m-lines
   in the bundle? (That currently seems to be required.)
   If set to 'new', won't that force renegotiation of the DTLS,
   including possibly a new IP address?

- if an error occurs on the SCTP association, but not on the DTLS
   connection, what does one do to recover? One might want to
   reinitialize the association, but how does one signal that?
   Offering a=connection:new would be one way, but it has all the
   same problems in the previous case.

I realize these don't belong in CLUE docs. Where do they belong? I guess 
in the mmusic wg, but wrt what draft?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Mar 2014 18:50:01 +0000

Hi,

> Maybe that isn't what you meant. But if so then again it seems unclear

The safest way could be to say that whoever detects the failure shall send a new offer. If both endpoints do it, the o/a race condition rules will take care of it.

-----------------

>>>> I actually think that both 5.4 and 5.5 belong to the sctp-sdp draft. There needs to be a common way for establishing the SCTPoDTLS assocation, and >>>> there is nothing CLUE specific in the text.
>>>

I don't think there is an existing DTLS connection. DTLS is only used for the RTP key exchange, isn't it?

In general, the SDP attribute considerations for BUNDLE shall be described in Suhas' draft.

>   same problems in the previous case.

I think this also belongs to the sdp-sctp draft.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Mar 2014 16:03:08 -0400

> The safest way could be to say that whoever detects the failure shall send a new offer. If both endpoints do it, the o/a race condition rules will take care of it.

I agree.

> I don't think there is an existing DTLS connection. DTLS is only used for the RTP key exchange, isn't it?

I checked 5763, and see that a=connection MUST NOT be used for 
DTLS/SRTP, though a=setup is used.

I'm no expert, but I don't think there is any difference. The DTLS setup 
still needs to be done. It would simplify things if that isn't so.

> In general, the SDP attribute considerations for BUNDLE shall be described in Suhas' draft.

OK. We can try that.

> I think this also belongs to the sdp-sctp draft.

It isn't evident to me that the issues with bundle belong in that draft.

Maybe in Suhas' draft, though this seems to be of a different character 
from the other things it deals with.

	Thanks,
	Paul