Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Christian's comments

From: Christer Holmberg <[email-masked]>
Date: Fri, 6 Feb 2015 11:22:33 +0000

Hi Christian,

Thanks for your comments. See inline.

> 1. General: I-D.ejzak- mmusic-data-channel-sdpneg has been made a WG draft <draft-ietf-mmusic-data-channel-sdpneg-00>.

If you look in the Reference section, I am actually referencing the draft-ietf-mmusic version :)

But, I did not change the reference tag. I can do that.

-----------

> 2. Section 3.2.1.1: Given that the general feeling is that UDP will be more common than TCP do we want to make a 
> recommendation on what transport CLUE endpoint should support in order to maximise interop?

I guess we could say that TCP SHOULD only be used if needed for ICE purpose.

But, I'd like to make sure other are ok with such approach too.

-----------

> 3. Section 3.2.2 Heading: dcpmap -> dcmap

Will be fixed.

-----------

> 4. Section 3.2.2: Perhaps we should explicitly mention the data channel type used from [I-D.ietf-rtcweb-data-protocol] e.g. 
> DATA_CHANNEL_RELIABLE.
> If it is only DATA_CHANNEL_RELIABLE then perhaps we should indicate in Table 2 that the 
> ordered, max-retr and max-time are not used due to the use of a reliable channel.

I support that.

-----------

> 5. Section 3.3.5: Therefor -> Therefore

Will be fixed.

-----------

> 6. Section 3.3.6: Change "... in order to close data channel, a SCTP reset 
> message [RFC6525] is sent to close the SCTP stream associated with the 
> data channel". It should read better without the "," and the second "in order".

Will be fixed.

-----------

> 7. Section 5.1/5.2: The registries that need to be used for DCMAP and the 
> WebRTC sub-protocol registry need to be sorted out. I'm not sure why two registries 
> would be needed for essentially the same thing.

I agree. I suggest to send an e-mail to the MMUSIC list regarding that, and suggest that the same registry is used.

-----------

> 8. General: I don't think we can ship this off to the IESG until we can be sure 
> that draft-ietf-mmusic-data-channel-sdpneg is stable.

My understanding is that we can do that, but that it will be kept in the RFC Editor's Queue due to pending dependency.

However, if we want to keep in in the WG, I have no problem with that.

I hope the chairs and/or AD can give some guidance on this.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Feb 2015 11:01:24 -0500

> But, I did not change the reference tag. I can do that.

Using TCP can cause bad head of line blocking issues for SCTP, between 
different streams. (Not so bad if there is only one stream in each 
direction and that is an ordered and reliable one.)

I think the SHOULD would be a good idea.

>> 3. Section 3.2.2 Heading: dcpmap -> dcmap

There isn't much practical difference between the two ways. Holding it 
in the wg is fine as long as the work group is around and functioning 
and paying attention. Putting it in the queue puts it on "auto pilot", 
so we need not do anything more.

I guess I would say that we can hold onto it until all the other drafts 
are ready for submission. At that point I am inclined to submit this one 
too. But we could do it sooner if people feel a need to claim completion 
of the milestone.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 6 Feb 2015 21:41:27 +0000

Hi,

>>> 2. Section 3.2.1.1: Given that the general feeling is that UDP will 
>>> be more common than TCP do we want to make a recommendation on 
>>> what transport CLUE endpoint should support in order to maximise interop?
>>
> Using TCP can cause bad head of line blocking issues for SCTP, between different 
> streams. (Not so bad if there is only one stream in each direction and that is an 
> ordered and reliable one.)
>

I can add some text.

...eventhough I think the issues with TCP (presented by Paul) should be described in the base WebRTC Data Channel draft, or in the SCTP over DTLS encapsulation draft.

But, as some of us know, those drafts don't say much (if anything) about TCP to begin with...

...

>>> 8. General: I don't think we can ship this off to the IESG until we 
>>> can be sure that draft-ietf-mmusic-data-channel-sdpneg is stable.
>>
> There isn't much practical difference between the two ways. Holding it in the wg is fine as long as the work group is around and > functioning and paying attention. Putting it in the queue puts it on "auto pilot", so we need not do anything more.
>
> I guess I would say that we can hold onto it until all the other drafts are ready for submission. At that point I am inclined to 
> submit this one too. But we could do it sooner if people feel a need to claim completion of the milestone.

Personally I think we can keep it in the working group at least until the other drafts are ready for submission.

Also, in addition to the SDP-NEG draft, the CLUE data channel draft is depending on the WebRTC Data Channel draft and the SDP-SCTP drafts to be finalized, so it is probably going to take a while until we get an RFC number anyway.

Finally, if there are any changes in other drafts, that affect the CLUE data channel draft, I guess it is easier to make changes if the draft is in the working group.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 8 Feb 2015 14:18:58 +0000

Hi,

>> 2. Section 3.2.1.1: Given that the general feeling is that UDP will be 
>> more common than TCP do we want to make a recommendation on 

What about adding the following text:

	"CLUE entities SHOULD NOT use the transport the SCTPoDTLS association used to realize
	the CLUE Data Channel over TCP (using the "TCP/DTLS/SCTP" proto value), unless 
	the the Interactive Connectivity Establishment (ICE) mechanism [RFC5245] is used and 
	the ICE procedures determines that TCP transport is required."

-----------

>> If it is only DATA_CHANNEL_RELIABLE then perhaps we should indicate in 
>> Table 2 that the ordered, max-retr and max-time are not used due to the use of a reliable channel.
>
> I support that.

What about adding the following text:

	"NOTE: As CLUE entities are required to use ordered SCTP message delivery,
	with full reliability, according to the procedures in [I-D.ietf-mmusic-data-channel-sdpneg]
 	the ordered, max-retr and max-time attribute parameters are not used when 
	negotiating CLUE data channels."

-----------

>> 7. Section 5.1/5.2: The registries that need to be used for DCMAP and 
>> the WebRTC sub-protocol registry need to be sorted out. I'm not sure 
>> why two registries would be needed for essentially the same thing.
>

I sent an e-mail regarding this to the MMUSIC list. 

Regards,

Christer

---

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 9 Feb 2015 11:52:25 -0800

I agree with Christer's proposed new text for items 2 and 4 below.
Mark

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: Sunday, February 08, 2015 9:19 AM
> To: Christian Groves; [email-masked]
> Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February -
> Christian's comments
> 
> 
> Hi,
> 
> >> 4. Section 3.2.2: Perhaps we should explicitly mention the data channel
> type used from [I-D.ietf-rtcweb-data-protocol] e.g.
> >> DATA_CHANNEL_RELIABLE.
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Christian Groves <[email-masked]>
Date: Tue, 10 Feb 2015 15:41:47 +1100

Hello Christer,

> 	the ICE procedures determines that TCP transport is required."
[CNG] I think there's one "the" too many in the first line. Should it 
read "CLUE entities SHOULD NOT transport the SCTPoDTLS association used 
to realize..."?

Regards, Christian

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 Feb 2015 07:24:06 +0000

Hi,

>>>> be more common than TCP do we want to make a recommendation on what 
>>>> transport CLUE endpoint should support in order to maximise interop?
> [CNG] I think there's one "the" too many in the first line. Should it read "CLUE entities SHOULD NOT transport the SCTPoDTLS association used to realize..."?

Correct. I'll fix that.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Feb 2015 18:06:39 -0500

> 	the ICE procedures determines that TCP transport is required."

WFM

This is good, except that we should not exclude the possibility of 
explicitly specifying reliable ordered delivery, by including 'ordered' 
with the appropriate value. (I can't tell whether that is "0" or "1". 
Right how the text defines them both as meaning ordered.)

Clearly this needs to be defined there. But I agree that there should 
not be separate registries.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 Feb 2015 08:06:54 +0000

Hi,

...

>>>> If it is only DATA_CHANNEL_RELIABLE then perhaps we should indicate 
>>>> in Table 2 that the ordered, max-retr and max-time are not used due to the use of a reliable channel.
>>>
>>> I support that.
>>
> This is good, except that we should not exclude the possibility of explicitly specifying reliable ordered delivery, by including 'ordered' 

Correct.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Feb 2015 12:48:48 -0500

>> [CNG] I think there's one "the" too many in the first line. Should it read "CLUE entities SHOULD NOT transport the SCTPoDTLS association used to realize..."?

It is corrected in -08. But after thinking about it further, I think 
should not restrict this usage to ICE. There may be other circumstances 
when it is known that UDP won't work. So how about:

    CLUE entities SHOULD NOT transport the SCTPoDTLS association used to
    realize the CLUE data channel over TCP (using the "TCP/DTLS/SCTP"
    proto value), unless it is known that UDP/DTLS/SCTP will not work.
    (For instance, when the the Interactive Connectivity Establishment
    (ICE) mechanism [RFC5245] is used and the ICE procedures determine
    that TCP transport is required.)

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Feb 2015 12:59:31 -0500

>> Right how the text defines them both as meaning ordered.)

I'm ok with table 2 now. But I think it would be good for the example in 
3.3.4 (table 1) to show the use of the ordered attribute:

            m=application 54111 UDP/DTLS/SCTP webrtc-datachannel
            a=sctp-port: 5000
            a=dcmap:2 subprotocol="CLUE";ordered=true

That doesn't depend on the default value for ordered.

	Thanks,
	Paul

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Fri, 13 Feb 2015 18:25:36 +0000

> That doesn't depend on the default value for ordered.
[Raju] Proposed default is ordered=true.

BR
Raju

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Feb 2015 22:48:04 +0000

Hi,

>>>>>> 2. Section 3.2.1.1: Given that the general feeling is that UDP 
>>>>>> will be more common than TCP do we want to make a recommendation 
>>>>>> on what transport CLUE endpoint should support in order to maximise interop?
>>> [CNG] I think there's one "the" too many in the first line. Should it read "CLUE entities SHOULD NOT transport the SCTPoDTLS >>> association used to realize..."?
>>
>> Correct. I'll fix that.
>
> It is corrected in -08. But after thinking about it further, I think should not restrict this usage 
> to ICE. There may be other circumstances when it is known that UDP won't work. So how about:
>

Looks good. I'll fix it in version -09.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Feb 2015 22:56:18 +0000

Hi,

>>> This is good, except that we should not exclude the possibility of explicitly specifying 
>>> reliable ordered delivery, by including 'ordered'

I'll add the ordered parameter with a true value (I assume it will be defined as a token, and not a quoted string) to the example in version -09.

Thanks!

Regards,

Christer