Subject: Re: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-09

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Oct 2016 06:17:47 +0000

Hi,

>Regarding the establishment of a new SCTP association, yes, agree that the
simplest way could be to request new sctp-port values being used - provided a
new SDP offer/answer exchange
>is used. Would SCTP association endpoints be allowed to autonomously establish
a new SCTP association using the old sctp-port values if the previous SCTP
association failed for any reason. So far I would assume yes.

I would assume so too.
 
>Regarding the explicit closure of an SCTP association while keeping the DTLS
association - right now I also only would have the BUNDLE case in mind which you
are mentioning.
>That could indeed be a valid use case as far as I am concerned.

So,  I guess we could define usage of sctp-port with a zero value for that.

Regards,

Christer

 
On 28.09.2016 17:28, Christer Holmberg wrote:

>     
>  
> 
> Hi,
>  
> 
>>  >Thanks for further feedback.
>>  >The first bullet point of section 10.5 in draft-ietf-mmusic-sctp-sdp-17
>> says:
>>  >"Unless the offerer wants to re-establish an SCTP association, the offerer
>> MUST associate an
>>  >SDP 'sctp-port' attribute, with a new attribute value, with the m- line..."
>>  >
>>  >Now I am not sure anymore regarding the meaning of "re-established" in this
>> context.
>>  >If the previous SCTP association is closed, and if then a new SCTP
>> association is established, is the idea to distinguish between a
>> "re-establishment", where >the formerly used "sctp-port" values are re-used,
>> and a "new establishment", where new values of "sctp-port" are used?
>  
>  I was just having a chat with Roman about that.
>  
> In my opinion, the most simply way would be to say that whenever a new SCTP
> association is established, one MUST use a different sctp-port value than the
> previously used  no matter if the previous SCTP association exists or not.
>  
> Another question is whether the closure of an SCTP association requires
> explicit signalling. In that case, perhaps using a sctp-port value of zero?
> One can obviously set the m- line port to zero, which will close both the DTLS
> association and the SCTP association  but the question is whether there is a
> use-case where one would only want to close the SCTP association, without
> touching the DTLS association. BUNDLE?
>  
> Regards,
>  
> Christer
>  
>  
>  
>  
>  
> 
>  Thanks again,
>  Juergen
>  
>  
>  
>  
> 
> On 28.09.2016 15:04, Christer Holmberg wrote:
>  
>  
>>  
>>  
>> 
>> Hi,
>>  
>>  
>>  
>> 
>>  
>>  
>>  
>>  
>> 
>> As specified in draft-ietf-mmusic-sctp-sdp, the SCTP association and DTLS
>> association are handled independently of each other.
>>  
>>  
>>  
>> 
>>  
>>  
>>  
>>  
>> 
>> And, in order to re-establish an SCTP association, an endpoint needs to
>> provide a new SDP 'sctp-port' attribute value.
>>  
>>  
>>  
>> 
>>  
>>  
>>  
>>  
>> 
>> Regards,
>>  
>>  
>>  
>> 
>>  
>>  
>>  
>>  
>> 
>> Christer
>>  
>>  
>>  
>> 
>>  
>>  
>>  
>>  
>> 
>> From: mmusic <[email-masked]> on behalf of Roman Shpount
>> <[email-masked]>
>>  Date: Wednesday 28 September 2016 at 15:34
>>  To: Juergen Stoetzer-Bradler <[email-masked]>
>>  Cc: "[email-masked]" <[email-masked]>
>>  Subject: Re: [MMUSIC] WG Last Call for
>> draft-ietf-mmusic-data-channel-sdpneg-09
>>  
>>  
>>  
>> 
>>  
>>  
>>  
>>  
>>  
>>  
>> 
>> Juergen,
>>  
>>  
>> 
>>  
>>  
>>  
>>  
>> 
>> This was my understanding as well but I would also like the rest of the group
>> to confirm.
>>  
>>  
>>  
>> 
>>  
>>  
>>  
>>  
>> 
>> Regards,
>>  
>>  
>>  
>>  
>> 
>> 
>>  
>>  
>>  
>>  
>> 
>> _____________
>>  Roman Shpount
>>  
>>  
>>  
>>  
>>  
>>  
>> 
>> On Wed, Sep 28, 2016 at 7:39 AM, Juergen Stoetzer-Bradler
>> <[email-masked]> wrote:
>>  
>>>  
>>>  
>>> 
>>> Roman,
>>>  
>>>  As per my understanding it should indeed be allowed to shutdown an SCTP
>>> association and then to establish a new one over the same DTLS association.
>>> Both SCTP association endpoints would have to choose new values for the
>>> initiate tags / verification tags, such that received SCTP packets could be
>>> uniquely associated with either the previous or the new SCTP association.
>>>  However, I am not an SCTP expert - might be good to hear additional
>>> feedback.
>>>  
>>>  Best regards,
>>>  Juergen 
>>>  
>>>  
>>>  
>>> 
>>>  
>>>  
>>>  
>>> 
>>> On 27.09.2016 20:19, Roman Shpount wrote:
>>>  
>>>  
>>>>  
>>>>  
>>>> 
>>>> Juergen, 
>>>>  
>>>>  
>>>> 
>>>>  
>>>>  
>>>>  
>>>>  
>>>> 
>>>> The proposed language looks good.
>>>>  
>>>>  
>>>>  
>>>> 
>>>>  
>>>>  
>>>>  
>>>>  
>>>> 
>>>> After reading the multiplexing language, I have a related question: Is it
>>>> allowed to tear down the SCTP association and setup a new SCTP association
>>>> over the same DTLS association?
>>>>  
>>>>  
>>>>  
>>>> 
>>>>  
>>>>  
>>>>  
>>>>  
>>>> 
>>>> Regards,
>>>>  
>>>>  
>>>>  
>>>>  
>>>> 
>>>> 
>>>>  
>>>>  
>>>>  
>>>>  
>>>> 
>>>> _____________
>>>>  Roman Shpount
>>>>  
>>>>  
>>>>  
>>>>  
>>>>  
>>>>  
>>>> 
>>>> On Tue, Sep 27, 2016 at 8:11 AM, Juergen Stoetzer-Bradler
>>>> <[email-masked]> wrote:
>>>>  
>>>>>  
>>>>>  
>>>>> 
>>>>> Roman, Paul,
>>>>>  
>>>>>  Based on your comments I would propose to modify the text in the
>>>>> introduction and in the dcmap and dcsa multiplexing category sections as
>>>>> follows.
>>>>>  I've removed all text parts, in which the "m" line proto values "SCTP"
>>>>> and "SCTP/DTLS" had been mentioned.
>>>>>  
>>>>>  Are you ok with these changes?
>>>>>  
>>>>>  Thanks again,
>>>>>  Juergen
>>>>>  
>>>>> 1.  Introduction
>>>>>  
>>>>>  
>>>>>  
>>>>>    The RTCWeb working group has defined the concept of bi-directional
>>>>>  
>>>>>    data channels running on top of the Stream Control Transmission
>>>>>  
>>>>>    Protocol (SCTP).  ...
>>>>>  
>>>>>    
>>>>>  
>>>>>    ...
>>>>>  
>>>>>    
>>>>>  
>>>>>    This document defines SDP offer/answer negotiation procedures to
>>>>>  
>>>>>    establish data channels for transport of well-defined subprotocols,
>>>>>  
>>>>>    to enable out-of-band negotiation.  These procedures are based on
>>>>>  
>>>>>    generic SDP offer/answer negotiation rules for SCTP based media
>>>>>  
>>>>>    transport as specified in [I-D.ietf-mmusic-sctp-sdp] for the SDP "m"
>>>>>  
>>>>>    line proto values UDP/DTLS/SCTP and TCP/DTLS/SCTP.  In future data
>>>>>  
>>>>>    channels could be defined over other SCTP based protocols, such as
>>>>>  
>>>>>    SCTP over IP.  However, corresponding potential other "m" line proto
>>>>>  
>>>>>    values are not considered in this document.
>>>>>  
>>>>>  
>>>>>  
>>>>>    ...
>>>>>  
>>>>>  
>>>>>  
>>>>> 5.1.1.2.  dcmap Multiplexing Category
>>>>>  
>>>>>  
>>>>>  
>>>>>    ...
>>>>>  
>>>>>  
>>>>>  
>>>>>    As the usage of multiple SCTP associations on top of a single DTLS
>>>>>  
>>>>>    connection is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no
>>>>>  
>>>>>    "a=dcmap:" attribute multiplexing rules are specified for the
>>>>>  
>>>>>    UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values.  If future extensions
>>>>>  
>>>>>    of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of
>>>>>  
>>>>>    multiple SCTP associations on top of a single DTLS connection, or how
>>>>>  
>>>>>    to add multiple SCTP associations to one BUNDLE group, then
>>>>>  
>>>>>    multiplexing rules for the "a=dcmap:" attribute need to be defined as
>>>>>  
>>>>>    well, for instance in an extension of this SDP based data channel
>>>>>  
>>>>>    negotiation specification.
>>>>>  
>>>>>  
>>>>>  
>>>>> 5.1.2.2.  dcsa Multiplexing Category
>>>>>  
>>>>>  
>>>>>  
>>>>>    ...
>>>>>  
>>>>>  
>>>>>  
>>>>>    As the usage of multiple SCTP associations on top of a single DTLS
>>>>>  
>>>>>    connection is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no
>>>>>  
>>>>>    "a=dcsa:" attribute multiplexing rules are specified for the
>>>>>  
>>>>>    UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values.  If future extensions
>>>>>  
>>>>>    of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of
>>>>>  
>>>>>    multiple SCTP associations on top of a single DTLS connection, or how
>>>>>  
>>>>>    to add multiple SCTP associations to one BUNDLE group, then
>>>>>  
>>>>>    multiplexing rules for the "a=dcsa:" attribute need to be defined as
>>>>>  
>>>>>    well, for instance in an extension of this SDP based data channel
>>>>>  
>>>>>    negotiation specification.
>>>>>  
>>>>>  
>>>>>  
>>>>> 
>>>>>  
>>>>>  
>>>>>  
>>>>> 
>>>>> On 21.09.2016 14:17, Juergen Stoetzer-Bradler wrote:
>>>>>  
>>>>>  
>>>>>>  
>>>>>> Roman, Paul,
>>>>>>  
>>>>>>  Thanks for your comments.
>>>>>>  
>>>>>>  The protocol stack notation "SCTP/DTLS" in the introduction was actually
>>>>>> meant to refer to the "SCTP on top of DTLS" case, which is also mentioned
>>>>>> in the succeeding parentheses. I fully agree that this is confusing and
>>>>>> would propose to remove "SCTP/DTLS" from the introduction and instead to
>>>>>> just say:
>>>>>>  "The RTCWeb working group has defined the concept of bi-directional data
>>>>>> channels running on top of SCTP over the Datagram Transport Layer
>>>>>> Security protocol.".
>>>>>>  Or just "... on top of SCTP over DTLS".
>>>>>>  
>>>>>>  And indeed, as draft-ietf-mmusic-sctp-sdp doesn't contain m-line proto
>>>>>> value "SCTP/DTLS" at all anymore, I would agree to remove it from
>>>>>> sections 5.1.1.2 and 5.1.2.2.
>>>>>>  Also agree to restrict the scope of the whole document to the two
>>>>>> "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP" transport stack cases and to
>>>>>> explicitly say so e.g. in the introduction. This would be inline with the
>>>>>> definition of "data channel" in the terminology section, which explicitly
>>>>>> refers to draft-ietf-rtcweb-data-channel, where only these two transport
>>>>>> stack cases are considered.
>>>>>>  
>>>>>>  Regards,
>>>>>>  Juergen
>>>>>>  
>>>>>>  
>>>>>> 
>>>>>> On 16.09.2016 01:30, Roman Shpount wrote:
>>>>>>  
>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>> 
>>>>>>> On Thu, Sep 15, 2016 at 6:54 PM, Paul Kyzivat <[email-masked]>
>>>>>>> wrote:
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>> 
>>>>>>> On 9/15/16 5:51 PM, Roman Shpount wrote:
>>>>>>>  
>>>>>>>  
>>>>>>> RTCWeb defines data channels running over DTLS/SCTP (SCTP over the
>>>>>>>  Datagram Transport Layer Security protocol) not SCTP/DTLS which is DTLS
>>>>>>>  over SCTP and is a completely different thing.
>>>>>>>  
>>>>>>>  
>>>>>>> 
>>>>>>>  SCTP/DTLS is now gone, so we don't need to consider it.
>>>>>>>  
>>>>>>>  IIUC RTCWEB needs for data channels to be defined over at least two
>>>>>>> lower layers: UDP/DTLS/SCTP and TCP/DTLS/SCTP. (Because ICE might end up
>>>>>>> having to run over TCP rather than UDP.)
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>> 
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>> 
>>>>>>> SCTP/DTLS is mentioned in the introduction
>>>>>>> (https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-09#se
>>>>>>> ction-1). Should be replaced with UDP/DTLS/SCTP and TCP/DTLS/SCTP.
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>> 
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>> Do we even define data channels on top of SCTP and SCTP/DTLS transports?
>>>>>>>  These are definitely not used in RTCWeb. I think these should be
>>>>>>> removed
>>>>>>>  from the document.
>>>>>>>  
>>>>>>>  
>>>>>>> 
>>>>>>>  Fundamentally data channels are defined over SCTP. Whether that is over
>>>>>>> UDP, TCP or IP or something else is irrelevant to its definition. The
>>>>>>> only thing that is relevant is to have a <proto> value that has SCTP on
>>>>>>> top, and for both ends to agree on that. (And those proto values are
>>>>>>> defined in draft-ietf-mmusic-sctp-sdp, not here.)
>>>>>>>  
>>>>>>>  So why does this draft have to say *anything* about what is under SCTP?
>>>>>>> That is just a matter for each specific usage.
>>>>>>>  
>>>>>>>  But, if that is too much of a change, then I guess the next best is to
>>>>>>> only define UDP/DTLS/SCTP and TCP/DTLS/SCTP, and note that definition
>>>>>>> for use of SCTP over other lower layers is left for future definition.
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>> 
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>> 
>>>>>>> The document mentions SCTP/DTLS as well as SCTP in the same list as
>>>>>>> UDP/DTLS/SCTP and TCP/DTLS/SCTP
>>>>>>> (https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-09#se
>>>>>>> ction-5.1.1.2 and
>>>>>>> https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-09#sec
>>>>>>> tion-5.1.2.2 for instance). These mentions should be removed. If needed,
>>>>>>> introduction can mention that data channel can be defined in the future
>>>>>>> over other SCTP based protocols, such as plain SCTP and SCTP/DTLS.
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>> 
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>> 
>>>>>>> Regards, 
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>> 
>>>>>>> _____________
>>>>>>>  Roman Shpount
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>> 
>>>>>>>  ailman/listinfo/mmusic
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>  
>>>>>>  
>>>>>>  
>>>>>  
>>>>>  
>>>>>  
>>>>>  
>>>>>  
>>>>>  
>>>>> 
>>>>> _______________________________________________
>>>>>  mmusic mailing list
>>>>>  [email-masked]
>>>>>  https://www.ietf.org/mailman/listinfo/mmusic
>>>>>  
>>>>  
>>>>  
>>>>  
>>>>  
>>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>  
>  
>  
>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 7 Oct 2016 08:38:31 -0400

On Thu, Sep 29, 2016 at 8:39 AM, Juergen Stoetzer-Bradler <
[email-masked]> wrote:

> simplest way could be to request new sctp-port values being used - provided
> a new SDP offer/answer exchange is used. Would SCTP association endpoints
> be allowed to autonomously establish a new SCTP association using the old
> sctp-port values if the previous SCTP association failed for any reason. So
> far I would assume yes.
>

Would both end points agree that SCTP association failed at the same time?
Would they be able to restart SCTP association at the same time? SCTP setup
is active/active in the current draft. Unless both endpoints detect the
failure simultaneously and recover from whatever caused it sententiously,
they will not both start to re-establish the connection at the same time.
It would be much cleaner if SCTP association would only be re-established
after O/A exchange. Furthermore, SCTP should be able to handle short
network connectivity disruptions. If SCTP actually failed, it means
something fairly serious happened with the network connection (or client
stack). It is unclear that SCTP association would easily automatically
recover in such cases.

Also, I assume you do not want to automatically re-establish an SCTP
association if one of the end points gracefully closes it using SCTP
SHUTDOWN.
_____________
Roman Shpount