Subject: [MMUSIC] New draft version: draft-ietf-mmusic-msrp-usage-data-channel-01

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Mon, 9 Mar 2015 12:05:29 +0100

Hello,

Have also submitted version -01 of draft-ietf-mmusic-msrp-usage-data-channel.
The changes as compared to version -00 are listed below and are related to corresponding recent 
email list discussions.
This list is also copied to the change log section 10.1.

Thanks,
Juergen

    o  Additional reference to [I-D.ietf-mmusic-data-channel-sdpneg] in
       list of normative references.

    o  Replacement of previous document title "MSRP over SCTP/DTLS data
       channels" with "MSRP over Data Channels" in order to align with
       the terminology used in [I-D.ietf-mmusic-data-channel-sdpneg].

    o  In Section 3 "WebRTC data channel" was defined as "A bidirectional
       channel consisting of paired SCTP outbound and inbound streams."
       Replacement of this definition with "Data channel: A WebRTC data
       channel as specified in [I-D.ietf-rtcweb-data-channel]", and
       consistent usage of either "data channel" or "MSRP data channel"
       in the remainder of the document."

    o  In the introduction replacement of references to
       [I-D.ietf-rtcweb-data-protocol] with a reference to
       [I-D.ietf-rtcweb-data-channel].

    o  Consistent usage of '"m" line' in whole document as per [RFC4566].

    o  In the gateway configuration section (Section 6) replacement of
       the first sentence "This section describes the network
       configuration where one endpoint runs MSRP over a WebRTC SCTP/DTLS
       connection, the other MSRP endpoint runs MSRP over one or more
       TLS/TCP connections, and the two endpoints interwork via an MSRP
       gateway" with "This section describes the network configuration
       where one MSRP endpoint uses data channels as MSRP transport, the
       other MSRP endpoint uses TLS/TCP connections as MSRP transport,
       and the two MSRP endpoints interwork via an MSRP gateway".

---

From: Christian Groves <[email-masked]>
Date: Tue, 10 Mar 2015 14:25:58 +1100

Hello Juergen,

Thanks for the update. Some comments:
5.1.1.1 - The section indicates that the max-retr, max-time and
    ordered parameters shall not be used. I take it then that the SCTP 
Stream used for MSRP must be DATA_CHANNEL_RELIABLE? If so it might be 
better to say what is used rather than what is not.

5.1.1.1 - The text regarding the SCTP port can be removed because of 
recent changes to draft-ietf-mmusic-sctp-sdp removing the concept of 
default port.

5.1.1.2 1st paragraph - I propose to re-order to make it clear there's 
one dcsa line per MSRP specific attribute:

    The SDP offer shall also include within the media description
    for the SCTP association a dcsa attribute line (defined in
    [I-D.ietf-mmusic-data-channel-sdpneg]) for each MSRP-specific SDP 
attribute to be
    negotiated for each MSRP data channel being negotiated.

5.1.1.2: MSRP "max-size" would it be worth to note that this must be 
less than the SCTP SDP max-message-size value?

5.1.1.2: "Setup" is this relevant for MSRP using data channel? The 
SCTP-SDP draft etc. give rules as to which endpoint establishes 
different parts of the transport connection?

5.1.1.3: a=sctp-port 5000 should have a colon e.g. a=sctp-port:5000

5.1.5: This section indicates that closing is done as per 
I-D.ietf-mmusic-data-channel-sdpneg. However clause 
5.2.4/I-D.ietf-mmusic-data-channel-sdpneg indicates that closure is 
sub-protocol specific. Its not clear to me whether this the sub-protocol 
should indicate the use of the SCTP reset or the use of SDP O/A?

Regards, Christian

On 9/03/2015 10:05 PM, Juergen Stoetzer-Bradler wrote:
> Hello,
>
> Have also submitted version -01 of 
> draft-ietf-mmusic-msrp-usage-data-channel.
> The changes as compared to version -00 are listed below and are 
> related to corresponding recent email list discussions.
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Wed, 11 Mar 2015 16:41:47 +0100

Hello Christian,

Thanks much for your comments.
Please see my remarks inserted below.

Thanks,
Juergen

On 10.03.2015 04:25, Christian Groves wrote:
>    ordered parameters shall not be used. I take it then that the SCTP Stream used for MSRP must be 
> DATA_CHANNEL_RELIABLE? If so it might be better to say what is used rather than what is not.

[Juergen] Agree. Would propose to replaced current sentence "The max-retr, max-time and ordered 
parameters shall not be used" with
"Ordered and reliable data channels MUST always be used, such that the 'max-retr' and 'max-time' 
parameters SHALL NOT be used.
If the 'ordered' parameter is used, then its value MUST be equal to 'true'."

>
> 5.1.1.1 - The text regarding the SCTP port can be removed because of recent changes to 
> draft-ietf-mmusic-sctp-sdp removing the concept of default port.

[Juergen] Yes, agree. We'll remove the text in parentheses: "(on default SCTP port 5000)".

>
> 5.1.1.2 1st paragraph - I propose to re-order to make it clear there's one dcsa line per MSRP 
> specific attribute:
>
>    [I-D.ietf-mmusic-data-channel-sdpneg]) for each MSRP-specific SDP attribute to be

[Juergen] Indeed, that's clearer. We'll change the text as you propose.

>
> 5.1.1.2: MSRP "max-size" would it be worth to note that this must be less than the SCTP SDP 
> max-message-size value?

[Juergen] That's a good point. As far as I understand the a=max-message-size value
is related to the “maximum message size that an SCTP endpoint is willing to receive”
as per draft-ietf-mmusic-sctp-sdp-14, sec 6.1, whereas the MSRP specific a=max-size attribute
refers to the maximum MSRP message size an endpoint is willing to accept (as per 4975, sec 8.6),
thus is not related to the maximum MSRP message chunk size.
Would you be OK if we added a sentence to 5.1.1.2 saying that an MSRP session endpoint
MUST NOT send MSRP message chunks larger than  the peer’s a=max-message-size value?

>
> 5.1.1.2: "Setup" is this relevant for MSRP using data channel? The SCTP-SDP draft etc. give rules 
> as to which endpoint establishes different parts of the transport connection?

[Juergen] Good point, too. The msrp-usage draft requires MSRP UAs using data channel transport
to support the MSRP CEMA extension as described in RFC 6714. This again refers to RFC 6135,
which uses the a=setup attribute value to determine the "active" MSRP UA, which is responsible for 
sending
the initial MSRP SEND message (which might be empty).
Also msrp-usage draft's section 5.1.2 currently requests the "active" MSRP endpoint to send an
MSRP SEND message as as soon as the associated data channel instance is opened.
Per draft-ietf-mmusic-sctp-sdp-14 the "a=setup" attribute contained in the DTLS/SCTP based media 
description
is used to determine the TCP (if used) and DTLS client/server roles. But this usage of the "a=setup" 
attribute
is different than the usage of "a=setup" as described in RFC 6135's section 4.2.
I assume we may have to describe more explicitly in msrp-usage how it is determined if an MSRP endpoint
becomes "active" (and sends the initial MSRP SEND message).

> 5.1.1.3: a=sctp-port 5000 should have a colon e.g. a=sctp-port:5000

[Juergen] Thanks. We'll correct this.

>
> 5.1.5: This section indicates that closing is done as per I-D.ietf-mmusic-data-channel-sdpneg. 
> However clause 5.2.4/I-D.ietf-mmusic-data-channel-sdpneg indicates that closure is sub-protocol 
> specific. Its not clear to me whether this the sub-protocol should indicate the use of the SCTP 
> reset or the use of SDP O/A?

[Juergen] The intention in 5.1.5 is to refer to the generic data channel closure procedure based on
the SCTP stream reset mechanism, and that additionally per new SDP offer / answer exchange
the a=dcmap and a=dcsa attribute lines associated with the MSRP session need to be removed
from the DTLS/SCTP based media description.
Would you agree if we explicitly said:
“The closure of an MSRP session MUST be signaled via an SDP offer / answer exchange which
removes the "a=dcmap:" and "a=dcsa:" attribute lines associated with the MSRP session from
the associated DTLS/SCTP based media description.
This results in the associated data channel being closed as well as per 
[I-D.ietf-mmusic-data-channel-sdpneg].”

> Regards, Christian

[snip]

---

From: Christian Groves <[email-masked]>
Date: Thu, 12 Mar 2015 13:19:46 +1100

Hello Juergen,

No problem, please see my responses below.

Regards, Christian

On 12/03/2015 2:41 AM, Juergen Stoetzer-Bradler wrote:
> [Juergen] Agree. Would propose to replaced current sentence "The 
> max-retr, max-time and ordered parameters shall not be used" with
> "Ordered and reliable data channels MUST always be used, such that the 
> 'max-retr' and 'max-time' parameters SHALL NOT be used.
[CNG] OK
> ..snip..
[CNG] Yes.
> which uses the a=setup attribute value to determine the "active" MSRP 
> UA, which is responsible for sending
> Per draft-ietf-mmusic-sctp-sdp-14 the "a=setup" attribute contained in 
> the DTLS/SCTP based media description
> is used to determine the TCP (if used) and DTLS client/server roles. 
> But this usage of the "a=setup" attribute
[CNG] Yes I think its important to cover the this aspect.
>> sub-protocol specific. Its not clear to me whether this the 
>> sub-protocol should indicate the use of the SCTP reset or the use of 
>> SDP O/A?
>
> This results in the associated data channel being closed as well as 
> per [I-D.ietf-mmusic-data-channel-sdpneg].”
[CNG] This wording is better. Is the SCTP reset at the same time as the 
SDP Offer?

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Mon, 16 Mar 2015 17:49:37 +0100

Hello Christian,

Regarding your comment and question to section 5.1.5:

> [CNG] This wording is better. Is the SCTP reset at the same time as the SDP Offer? 

[Juergen] Actually, current text in section 5.2.4 of draft-ietf-mmusic-data-channel-sdpneg-01 
recommends (using SHOULD)
closing the data channel "after a successful SDP answer is sent/received".
In the MSRP case we would propose not to change this default behavior, which would result in the SDP 
answerer triggering
the reset procedure of its associated outgoing SCTP stream right after having accepted the received 
SDP offer with the data channel's
a=dcmap and a=dcsa attribute lines being removed, and close to the point in time it sends its SDP 
answer back to the SDP offerer.
I would assume that typically the SDP offerer would then see an outgoing SCTP stream reset request 
on its associated
incoming SCTP stream  before it receives the SDP answer.
Thus we could add this information and say:

“The closure of an MSRP session MUST be signaled via an SDP offer / answer exchange which
removes the "a=dcmap:" and "a=dcsa:" attribute lines associated with the MSRP session from
the associated DTLS/SCTP based media description.
This results in the associated data channel being closed as well as per 
[I-D.ietf-mmusic-data-channel-sdpneg],
where the actual data channel closure procedure is typically initiated by the SDP answerer right 
after having
accepted the SDP offer.”

Thanks again,
Juergen

On 12.03.2015 03:19, Christian Groves wrote:
>>>    ordered parameters shall not be used. I take it then that the SCTP Stream used for MSRP must 
>>> be DATA_CHANNEL_RELIABLE? If so it might be better to say what is used rather than what is not.
>>
>>> 5.1.1.2: "Setup" is this relevant for MSRP using data channel? The SCTP-SDP draft etc. give 
>>> rules as to which endpoint establishes different parts of the transport connection?
>>
>> which uses the a=setup attribute value to determine the "active" MSRP UA, which is responsible 
>> for sending
>> is used to determine the TCP (if used) and DTLS client/server roles. But this usage of the 
>> "a=setup" attribute
> [CNG] This wording is better. Is the SCTP reset at the same time as the SDP Offer?
>>
>>>
>>> Regards, Christian
>>>
>>>
>>
>> [snip]
>>

---

From: Christian Groves <[email-masked]>
Date: Tue, 17 Mar 2015 09:40:54 +1100

Hello Juergen,

Your proposed update sounds good to me.

Regards, Christian

On 17/03/2015 3:49 AM, Juergen Stoetzer-Bradler wrote:
> [Juergen] Actually, current text in section 5.2.4 of 
> draft-ietf-mmusic-data-channel-sdpneg-01 recommends (using SHOULD)
> In the MSRP case we would propose not to change this default behavior, 
> which would result in the SDP answerer triggering
> the reset procedure of its associated outgoing SCTP stream right after 
> having accepted the received SDP offer with the data channel's
> a=dcmap and a=dcsa attribute lines being removed, and close to the 
> point in time it sends its SDP answer back to the SDP offerer.
> I would assume that typically the SDP offerer would then see an 
> outgoing SCTP stream reset request on its associated
> per [I-D.ietf-mmusic-data-channel-sdpneg],
> where the actual data channel closure procedure is typically initiated 
> by the SDP answerer right after having
> accepted the SDP offer.”
>
> Thanks again,
> Juergen
>
>
>>>>    ordered parameters shall not be used. I take it then that the 
>>>> SCTP Stream used for MSRP must be DATA_CHANNEL_RELIABLE? If so it 
>>>> might be better to say what is used rather than what is not.
>>>
>>> "Ordered and reliable data channels MUST always be used, such that 
>>> the 'max-retr' and 'max-time' parameters SHALL NOT be used.
>>>> 5.1.1.2: MSRP "max-size" would it be worth to note that this must 
>>>> be less than the SCTP SDP max-message-size value?
>>>
>>> which uses the a=setup attribute value to determine the "active" 
>>> MSRP UA, which is responsible for sending
>>> Per draft-ietf-mmusic-sctp-sdp-14 the "a=setup" attribute contained 
>>> in the DTLS/SCTP based media description
>>>> sub-protocol should indicate the use of the SCTP reset or the use 
>>>> of SDP O/A?
>>>