Subject: [MMUSIC] draft-ietf-mmusic-data-channel-sdpneg-18.txt - proposed text for closing the data channel

From: "Roni Even (A)" <[email-masked]>
Date: Sun, 6 May 2018 07:20:41 +0000

Hi,
Based on the discussion here is the proposed text. The first stage is sending SCTP SSN reset by both sides and after this stage concludes  the second stage is to have an offer/answer to close or re-use the data channel

Thanks
Roni

Closing a Data Channel

If one side wants to close a data channel it MUST first reset the data channel by sending a SCTP SSN reset message on the corresponding outgoing stream/s [RFC6525].  When the peer sees that an incoming stream was reset, it also MUST send a SCTP SSN rest on its corresponding outgoing stream.  Resetting a stream resets the Stream Sequence Numbers (SSNs) of the stream back to 'zero' with a corresponding notification to the application layer that the reset has been performed.  Streams are available for re-use after a reset exchange has been performed. This restriction is to avoid the race conditions between arrival of SDP offer which reuses a stream with SCTP SSN reset which closes outgoing stream at the peer.

Since data channels can be opened using in-band protocol (DCEP) or out-of-band protocol (SDP), the next step depends on how the channel was opened. In the DCEP case the channel is now closed <rtcweb-data-channel>  If Offer/answer was used the application can close the channel or re-use it.
To close the data channel the application MUST send a new SDP offer which excludes the "a=dcmap:" and "a=dcsa:" attribute lines for this data channel.  The offerer SHOULD NOT change the port value for the "m" line (e.g. to zero) when closing a data channel (unless all data channels are being closed and the SCTP association is no longer needed), since this would close the SCTP association and impact all of the data channels.  If the answerer accepts the SDP offer then the answerer MUST exclude the corresponding attribute lines in the answer.  In addition to that, the SDP answerer MAY exclude other data channels which were closed but not yet communicated to the peer. So, the offerer MUST inspect the answer to see if it has to close other data channels that are now not included in the answer.

If a new SDP offer/answer is used to close data channels then the data channel(s) SHOULD only be closed by the answerer/offerer after a successful SDP answer is sent/received. This delayed closure is RECOMMENDED in order to handle cases where a successful SDP answer is not received, in which case the stateof the session SHOULD be kept per the last successful SDP offer/answer.

If the application wants to re-use the same stream-idor a new data channel, it MUST perform a new SDP offer/answer, describing the new subprotocol and its attributes. 

If the offer or the answer do not include any "a=dcmap" attributes all the SDP offer/answer negotiated data channels are expected to be closed now.  The DTLS/SCTP association remains open for new SDP offer/answer or DCEP negotiation of data channels.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 May 2018 11:45:43 +0000

Hi,

>Hi,
>Based on the discussion here is the proposed text. The first stage is
>sending SCTP SSN reset by both sides and after this stage concludes  the
>second stage is to have an offer/answer to close or re-use the data
>channel
>
>Thanks
>Roni
>
>Closing a Data Channel
>
>If one side wants to close a data channel it MUST first reset the data
>channel by sending a SCTP SSN reset message on the corresponding outgoing
>stream/s [RFC6525].  When the peer sees that an incoming stream was
>reset, it also MUST send a SCTP SSN rest on its corresponding outgoing
>stream.

Does RFC 6525 specific that both endpoints send SCTP SSN? If so, you don¹t
need the second MUST. Simply refer to the procedures in RFC6525.

>  Resetting a stream resets the Stream Sequence Numbers (SSNs) of the
>stream back to 'zero' with a corresponding notification to the
>application layer that the reset has been performed.  Streams are
>available for re-use after a reset exchange has been performed. This
>restriction is to avoid the race conditions between arrival of SDP offer
>which reuses a stream with SCTP SSN reset which closes outgoing stream at
>the peer.
>
>
>Since data channels can be opened using in-band protocol (DCEP) or
>out-of-band protocol (SDP), the next step depends on how the channel was
>opened. In the DCEP case the channel is now closed <rtcweb-data-channel>
>If Offer/answer was used the application can close the channel or re-use
>it.

I think it sounds strange to say "the application can close the channel or
re-use it² since the SCTP SSN already closed it.

I think you should say that the application must send an offer, where it
either "confirms the closure² or ³opens a new data channel for a different
sub-protocol².

In addition, I think you should say that it is the application that
initially sent SCTP SSN reset that sends the offer.

In addition, do we really want to indicate additional closed channels in
the answer? What would the offerer do if it hasn¹t receives SCTP SSN reset
for such data channels?

Regards,

Christer

---

From: "Roni Even (A)" <[email-masked]>
Date: Mon, 7 May 2018 12:33:32 +0000

Hi,
Inline

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Monday, May 07, 2018 2:46 PM
To: Roni Even (A); Paul Kyzivat; [email-masked]
Subject: Re: draft-ietf-mmusic-data-channel-sdpneg-18.txt - proposed text for closing the data channel

Hi,

>sending SCTP SSN reset by both sides and after this stage concludes  
>the second stage is to have an offer/answer to close or re-use the data 
>channel
>
>Thanks
>Roni
>
>Closing a Data Channel
>
>channel by sending a SCTP SSN reset message on the corresponding 
>outgoing stream/s [RFC6525].  When the peer sees that an incoming 
>stream was reset, it also MUST send a SCTP SSN rest on its 
>corresponding outgoing stream.

Does RFC 6525 specific that both endpoints send SCTP SSN? If so, you don¹t need the second MUST. Simply refer to the procedures in RFC6525.

<RE> I will reference https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13 closing data channel procedure
I will change the first paragraph to say

The closing data channel procedure from https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13  section 6.7 MUST be followed in order to close the data channel

>restriction is to avoid the race conditions between arrival of SDP 
>offer which reuses a stream with SCTP SSN reset which closes outgoing 
>stream at the peer.
>
>
>out-of-band protocol (SDP), the next step depends on how the channel 
>was opened. In the DCEP case the channel is now closed 
><rtcweb-data-channel> If Offer/answer was used the application can 
>close the channel or re-use it.

I think it sounds strange to say "the application can close the channel or re-use it² since the SCTP SSN already closed it.

I think you should say that the application must send an offer, where it either "confirms the closure² or ³opens a new data channel for a different sub-protocol².
 <RE> I will change the text accordingly ; the offer/answer is used to conform the closure of the data channel

In addition, I think you should say that it is the application that initially sent SCTP SSN reset that sends the offer.

<RE> OK, I assume it make sense since otherwise it will send an offer removing the stream-id attributes, note that the stream-id may contradict the rules for selecting ids but since it is re-use there is no problem with collision.

In addition, do we really want to indicate additional closed channels in the answer? What would the offerer do if it hasn¹t receives SCTP SSN reset for such data channels?
<RE> I will remove this text , it does not provide any value

Regards,

Christer

---

From: "Roni Even (A)" <[email-masked]>
Date: Mon, 7 May 2018 13:17:22 +0000

Hi ,
Here is the new text

Closing a Data Channel

In order to close the data channel, the closing data channel procedure from <draft-ietf-rtcweb-data-channel>  section 6.7 MUST be followed first.

Since data channels can be opened using in-band protocol (DCEP) or out-of-band protocol (SDP), the next step depends on how the channel was opened. In the DCEP case the channel is now closed < draft-ietf-rtcweb-data-channel >. If Offer/answer was used the application can confirm the closure of the channel or re-use it.
To confirm the closure of the data channel the application that initiated the closure procedure MUST send a new SDP offer which excludes the "a=dcmap:" and "a=dcsa:" attribute lines for this data channel.  The offerer SHOULD NOT change the port value for the "m" line (e.g. to zero) when confirming the closure of a data channel (unless all data channels are being closed and the SCTP association is no longer needed), since this would close the SCTP association and impact all of the data channels.  If the answerer accepts the SDP offer then the answerer MUST exclude the corresponding attribute lines in the answer.  

If a new SDP offer/answer is used to confirm the closure of data channels then the data channel(s) SHOULD only be closed by the answerer/offerer after a successful SDP answer is sent/received. This delayed closure is RECOMMENDED in order to handle cases where a successful SDP answer is not received, in which case the state of the session SHOULD be kept per the last successful SDP offer/answer.

If the application that initiated the closure wants to re-use the same stream-id for a new data channel subprotocol, it MUST perform a new SDP offer/answer, describing the new subprotocol and its attributes. 

Roni

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 May 2018 13:43:42 +0000

Hi,

>Closing a Data Channel
>
>In order to close the data channel, the closing data channel procedure
>from <draft-ietf-rtcweb-data-channel>  section 6.7 MUST be followed first.

I think you should say a little more than that. You can mention the SCTP
SSN reset procedures.

>opened. In the DCEP case the channel is now closed <
>draft-ietf-rtcweb-data-channel >. If Offer/answer was used the
>application can confirm the closure of the channel or re-use it.

I don¹t think you need to mention DCEP. Isn¹t there generic text saying
that the document defines SDP O/A procedures?

>To confirm the closure of the data channel the application that initiated
>the closure procedure MUST send a new SDP offer which excludes the
>"a=dcmap:" and "a=dcsa:" attribute lines for this data channel.  The
>offerer SHOULD NOT change the port value for the "m" line (e.g. to zero)
>when confirming the closure of a data channel (unless all data channels
>are being closed and the SCTP association is no longer needed), since
>this would close the SCTP association and impact all of the data
>channels.  If the answerer accepts the SDP offer then the answerer MUST
>exclude the corresponding attribute lines in the answer.

The answerer procedures belong in the answerer section.

>If a new SDP offer/answer is used to confirm the closure of data channels
>then the data channel(s) SHOULD only be closed by the answerer/offerer
>after a successful SDP answer is sent/received.

Again, the channels were already closed by the SCTP SSN reset, so do we
need this sentence?

I think this is old text, when the ³closure² offer was sent before the
SCTP SSN reset.

> This delayed closure is RECOMMENDED in order to handle cases where a
>successful SDP answer is not received, in which case the state of the
>session SHOULD be kept per the last successful SDP offer/answer.
>
>If the application that initiated the closure wants to re-use the same
>stream-id for a new data channel subprotocol, it MUST perform a new SDP
>offer/answer, describing the new subprotocol and its attributes.

Both peers can re-use the same stream-id for a new data channel, but the
application that initiated the closure can initiate the new data channel
already in the ³confirm² offer.

>If the offer or the answer do not include any "a=dcmap" attributes all
>the SDP offer/answer negotiated data channels are expected to be closed
>now.  The DTLS/SCTP association remains open for new SDP offer/answer or
>DCEP negotiation of data channels.

I think this sentence belongs to the generic section, specifying how a
subsequent offer looks like.

Regards,

Christer

---

From: "Roni Even (A)" <[email-masked]>
Date: Mon, 7 May 2018 14:05:10 +0000

Hi Christer,
Inline
Roni

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Monday, May 07, 2018 4:44 PM
To: Roni Even (A); Paul Kyzivat; [email-masked]
Subject: Re: draft-ietf-mmusic-data-channel-sdpneg-18.txt - proposed text for closing the data channel

Hi,

>from <draft-ietf-rtcweb-data-channel>  section 6.7 MUST be followed first.

I think you should say a little more than that. You can mention the SCTP SSN reset procedures.
<RE>OK

>was opened. In the DCEP case the channel is now closed < 

I don¹t think you need to mention DCEP. Isn¹t there generic text saying that the document defines SDP O/A procedures?
<RE> But the application need to check if it need to do offer /answer according to how the channel was opened

>To confirm the closure of the data channel the application that 
>initiated the closure procedure MUST send a new SDP offer which 
>excludes the "a=dcmap:" and "a=dcsa:" attribute lines for this data 
>channel.  The offerer SHOULD NOT change the port value for the "m" line 
>(e.g. to zero) when confirming the closure of a data channel (unless 
>all data channels are being closed and the SCTP association is no 
>longer needed), since this would close the SCTP association and impact 
>all of the data channels.  If the answerer accepts the SDP offer then 
>the answerer MUST exclude the corresponding attribute lines in the answer.

The answerer procedures belong in the answerer section.
<RE> I can remove the last sentence

>If a new SDP offer/answer is used to confirm the closure of data 
>channels then the data channel(s) SHOULD only be closed by the 
>answerer/offerer after a successful SDP answer is sent/received.

Again, the channels were already closed by the SCTP SSN reset, so do we need this sentence?
<RE> I think that the state is ambiguous until the offer/answer is concluded.  Since it is allowed to use either SDP or DCEP to open a data channel it will be good to clarify that the stream-id can only be after the offer/answer is concluded. This is the meaning of the rest of the paragraph
I think this is old text, when the ³closure² offer was sent before the SCTP SSN reset.

>offer/answer, describing the new subprotocol and its attributes.

Both peers can re-use the same stream-id for a new data channel, but the application that initiated the closure can initiate the new data channel already in the ³confirm² offer.
<RE> If the offer removed the dcmap with the closed stream-id, the rules about selecting odd/even id apply now so it is ot true that both peers can re-use the stream-id

>now.  The DTLS/SCTP association remains open for new SDP offer/answer 
>or DCEP negotiation of data channels.

I think this sentence belongs to the generic section, specifying how a subsequent offer looks like.

<RE> will move to 6.6

Regards,

Christer