Subject: [MMUSIC] SDP attribute setup=holdconn

From: Roman Shpount <[email-masked]>
Date: Tue, 30 Aug 2016 18:54:48 -0400

Hi All,

When discussing draft-ietf-mmusic-sctp-sdp with Christer we came up with a
question regarding handling setup=holdconn. In case of TCP/DTLS/SCTP, the
value of setup attribute is shared between TCP and DTLS. Per RFC 4145, TCP
defines a use case for setup=holdconn. At the same time per
draft-ietf-mmusic-dtls-sdp, setup=hodlconn must not be used. So, we have
two options here:

1. Forbid using setup=holdconn with TCP/DTLS/SCTP in
draft-ietf-mmusic-sctp-sdp
2. Define what setup=holdconn means for DTLS in draft-ietf-mmusic-dtls-sdp

To provide the original background, in case of TCP,  setup=holdconn
essentially means that new TCP connection cannot be established as a result
of this offer/answer exchange, no matter what other value has changed. It
is used to differentiate the case when connection=existing is used with a
passive TCP end point which wants to reuse existing connection and is not
ready to accept a new TCP connection. In other words, when passive end
point is ready to accept new TCP connection, the offer is sent with
connection=existing and setup=passive. When no accept method was issued on
the listening socket or if listening socket was already closed, the offer
is sent with connection=existing and setup=holdconn.

Since in case of DTLS, no accept method needs to be called on the socket
before sending an offer and no extra resources are needed to accept new
connection, I thought setup=holdconn was not necessary. This is why it was
specified in draft-ietf-mmusic-dtls-sdp, that setup=holdconn must not be
used. On the other hand there is no harm from setup=hodlconn. Furthermore
there are certain aesthetic benefits when setup=holdconn is used with ICE
and DTLS. When sending an update offer without ICE restart,
specifying setup=holdconn can be used to indicate that answerer is not
allowed to start a new DTLS association during this offer/answer exchange.

So, once again, what should we do with setup=holdconn? Update
draft-ietf-mmusic-dtls-sdp to define handling of setup=holdconn or prohibit
 setup=holdconn with TCP/DTLS/SCTP in draft-ietf-mmusic-sctp-sdp?

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Aug 2016 15:48:08 +0000

I am forwarding Roman’s e-mail to MMUSIC, because it think it belongs here.

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 31 August 2016 01:55
To: [email-masked]; [email-masked]
Cc: Christer Holmberg <[email-masked]>
Subject: SDP attribute setup=holdconn

Hi All,

When discussing draft-ietf-mmusic-sctp-sdp with Christer we came up with a question regarding handling setup=holdconn. In case of TCP/DTLS/SCTP, the value of setup attribute is shared between TCP and DTLS. Per RFC 4145, TCP defines a use case for setup=holdconn. At the same time per draft-ietf-mmusic-dtls-sdp, setup=hodlconn must not be used. So, we have two options here:

1. Forbid using setup=holdconn with TCP/DTLS/SCTP in draft-ietf-mmusic-sctp-sdp
2. Define what setup=holdconn means for DTLS in draft-ietf-mmusic-dtls-sdp

To provide the original background, in case of TCP,  setup=holdconn essentially means that new TCP connection cannot be established as a result of this offer/answer exchange, no matter what other value has changed. It is used to differentiate the case when connection=existing is used with a passive TCP end point which wants to reuse existing connection and is not ready to accept a new TCP connection. In other words, when passive end point is ready to accept new TCP connection, the offer is sent with connection=existing and setup=passive. When no accept method was issued on the listening socket or if listening socket was already closed, the offer is sent with connection=existing and setup=holdconn.

Since in case of DTLS, no accept method needs to be called on the socket before sending an offer and no extra resources are needed to accept new connection, I thought setup=holdconn was not necessary. This is why it was specified in draft-ietf-mmusic-dtls-sdp, that setup=holdconn must not be used. On the other hand there is no harm from setup=hodlconn. Furthermore there are certain aesthetic benefits when setup=holdconn is used with ICE and DTLS. When sending an update offer without ICE restart, specifying setup=holdconn can be used to indicate that answerer is not allowed to start a new DTLS association during this offer/answer exchange.

So, once again, what should we do with setup=holdconn? Update draft-ietf-mmusic-dtls-sdp to define handling of setup=holdconn or prohibit  setup=holdconn with TCP/DTLS/SCTP in draft-ietf-mmusic-sctp-sdp?

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Aug 2016 16:57:22 +0000

Hi,

My input on this.

>When discussing draft-ietf-mmusic-sctp-sdp with Christer we came up with a question regarding handling setup=holdconn. In case of >TCP/DTLS/SCTP, the value of setup attribute is shared between TCP and DTLS. Per RFC 4145, TCP defines a use case for setup=holdconn. At the same >time per draft-ietf-mmusic-dtls-sdp, setup=hodlconn must not be used. So, we have two options here:
>
>To provide the original background, in case of TCP,  setup=holdconn essentially means that new TCP connection cannot be established as a result of this >offer/answer exchange, no matter what other value has changed. It is used to differentiate the case when connection=existing is used with a passive TCP end >point which wants to reuse existing connection and is not ready to accept a new TCP connection. In other words, when passive end point is ready to accept >new TCP connection, the offer is sent with connection=existing and setup=passive. When no accept method was issued on the listening socket or if listening >socket was already closed, the offer is sent with connection=existing and setup=holdconn.
>
>Since in case of DTLS, no accept method needs to be called on the socket before sending an offer and no extra resources are needed to accept new >connection, I thought setup=holdconn was not necessary. This is why it was specified in draft-ietf-mmusic-dtls-sdp, that setup=holdconn must not be >used. On the other hand there is no harm from setup=hodlconn. Furthermore there are certain aesthetic benefits when setup=holdconn is used with ICE and >DTLS. When sending an update offer without ICE restart, specifying setup=holdconn can be used to indicate that answerer is not allowed to start a new >DTLS association during this offer/answer exchange.

I think it’s much better to have a general statement saying that the answerer should not start a new DTLS association, unless it has a good reason for doing so. IF the answerer has a good reason for starting a new DTLS association, do you really want to prevent it from doing so?

>So, once again, what should we do with setup=holdconn? Update draft-ietf-mmusic-dtls-sdp to define handling of setup=holdconn or >prohibit  setup=holdconn with TCP/DTLS/SCTP in draft-ietf-mmusic-sctp-sdp?

My hum goes for prohibiting setup=holdconn with TCP/DTLS/SCTP (and keeping draft-dtls-sdp unchanged).

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Wed, 31 Aug 2016 13:15:54 -0400

On Wed, Aug 31, 2016 at 12:57 PM, Christer Holmberg <
[email-masked]> wrote:

> I think it’s much better to have a general statement saying that the
> answerer should not start a new DTLS association, unless it has a good
> reason for doing so. IF the answerer has a good reason for starting a new
> DTLS association, do you really want to prevent it from doing so?
>
>
>
The issue here is the difference between should not and must not. If
offering TCP end point did not start the new accept call on the listening
socket, answering end point MUST NOT start a new connection -- there is no
socket to which it can connect. If offering ICE end point did not initiate
ICE restart, answering end point MUST NOT start a new DTLS association --
new DTLS association will be running over the same 5 tuple and it could not
be de-multiplexed from the previous DTLS association. The questions here
are:

1. Does anybody currently or would they ever in the future send TCP offer
with connection=existing and setup=holdconn? Is there a real scenario when
new connections are no longer expected but the TCP transport is still used?

2. Is there a reason to mark ICE updates offers with setup=holdconn for
DTLS? Answering end point can already see that it is not an ICE restart and
know that it MUST NOT start a new DTLS association.

If we answer no to all of those questions, we can safely prohibit
setup=holdconn. I am certainly in favor of fewer things to define and
implement, unless someone is using them.

Regards,
_____________
Roman Shpount