Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments

[Roman Shpount <[e-mail]>]

On Mon, Jan 23, 2017 at 7:13 PM, Ben Campbell <[e-mail]> wrote:

> On 21 Jan 2017, at 14:23, Christer Holmberg wrote:
>
>> -9.1, 2nd paragraph: Don't the lower layers need to be established before
>>> the
>>> upper layers? Won't removal of the TCP connection or DTLS association
>>> break
>>> an existing SCTP association?
>>>
>>
>> Roman had lots of input on this, so I'll let him reply.
>>
>
> Okay
>

Replacing of TCP connection or DTLS association does not break the SCTP
association. SCTP is designed to run over unreliable transports, so short
term loss of connectivity when one TCP connection or one DTLS association
is being replaced by the other would be handled by the SCTP re-transmit
timers. Also, when ICE is used, switching from one ICE candidate to
another, including switching between two ICE tcp candidates or switching
from udp to tcp candidate, does not affect existing SCTP association.
Existing SCTP association continues to run despite the underlying candidate
switch and as far as SCTP association is concerned it is running over the
same unreliable transport. Finally, DTLS association can be re-established
to force re-keying the long running connection. This can be done without
affecting SCTP association running on top of these DTLS associations.

This is why we are saying that the SCTP association, the DTLS association
and the TCP connection are managed independently from each other.  Each can
be established and  closed without impacting others. Each protocol uses its
own means to detect connection closure, failure or timeout.

I am also cautious of immediately closing SCTP association on TCP
connection or DTLS association closure. There are certain situations, when
these connections would be closed due to 3pcc collisions only to be
immediately opened again. I think, if SCTP association should be closed, it
needs to be explicitly signaled at SCTP level.

Regards,
_____________
Roman Shpount