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

From: Christer Holmberg <[email-masked]>
Date: Sat, 21 Jan 2017 20:23:04 +0000

Hi,

Below are my replies to Ben's technical comments.

----------------
Substantive Comments

> -1, first paragraph: RFC 5572-update is currently in IETF LC. Is there a reason not to reference it instead?

I assume you mean 4572-update :)

I agree that we should reference that spec instead, and I'll fix that.

----

> -4.1, last paragraph:
> I assume this paragraph refers to fmt values used with UDP/DTLS/SCTP or TCP/DTLS/SCTP, 
> not fmt values in general.

Correct. 

> It would help to be explicit about that.

The first sentence in section 4.1 does say:

   "This section defines the following new SDP Media Description (m-
   line) protocol identifiers (proto values) for describing an SCTP
   association: 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'."

> (Also, it seem like this paragraph belongs in section 4.3).

I could move and combine it with the 4th paragraph of section 4.3:

   "The m- line fmt value, identifying the application-layer protocol,
   MUST be registered by IANA. Section 15.3 defines the IANA registry 
   for the media format namespace."

----

> -4.5: The example is missing the sctp-port attribute.

I'll add it.

----

> -5.3: Why is the mux-category SPECIAL rather than CAUTION? IIUC, SPECIAL means you need to refer
> to the rules in the protocol definition. But the text here basically say that the rules are undefined.

I'm ok using CAUTION. I agree it might be more appropriate than SPECIAL.

----

> -6.1: What is meant by saying an "endpoint MUST assume that larger ... 
> will be rejected"? Can that be stated in terms of actual procedure (e.g. 
> "endpoint MUST NOT send...larger"?

I'd like Roman's input on this, in case he had some cases in mind where endpoint will have to send larger messages.

I guess we could say SHOULD NO send larger message, and explain that one cannot assume that larger message (if sent for whatever reason) will be accepted by the peer.

----

> -6.2, "Purpose" field: Please include the unit here, too.

I'll change to "maximum message size (indicated in bytes) that..."
                                 
----

> -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.

----

> -18.2: Seems like RFC0793 and RFC6544 should be normative references.

I'll fix that.

Regards,

Christer

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 23 Jan 2017 18:13:33 -0600

Thanks for the response. Replies inline.

Ben.

On 21 Jan 2017, at 14:23, Christer Holmberg wrote:

>> -1, first paragraph: RFC 5572-update is currently in IETF LC. Is 
>> there a reason not to reference it instead?
>

Yes :-)

>    association: 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'."

I'm not sure all readers will see the connection between the first and 
last paragraph. I still think it would help to explicitly mention it. 
(Especially if it moves to 4.3)

An alternative, if it were to stay in 4.1 would be to have the opening 
paragraph in 4.1 explicitly mention that it includes the fmt values to 
be used in the context of these new proto values.

>    for the media format namespace."

[...]

> I'm ok using CAUTION. I agree it might be more appropriate than 

I'm glad we agree :-) This is probably a big enough change to make sure 
the workgroup also agrees, though.

> I'd like Roman's input on this, in case he had some cases in mind 
> where endpoint will have to send larger messages.
>
> I guess we could say SHOULD NO send larger message, and explain that 
> one cannot assume that larger message (if sent for whatever reason) 
> will be accepted by the peer.

That would be reasonable if it is the right answer. I just want to avoid 
the vagueness of "MUST assume".

[...]

> Roman had lots of input on this, so I'll let him reply.

Okay

[...]

---

From: Roman Shpount <[email-masked]>
Date: Mon, 23 Jan 2017 20:16:53 -0500

>> Roman had lots of input on this, so I'll let him reply.

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 Jan 2017 13:20:46 +0000

Hi,

...

>>    for the media format namespace."

Ok, so my suggestion is to:

1) Move the paragraph to section 4.3, as described above
2) Modify the first paragraph in section 4.1:

"This section defines the following new SDP Media Description (m-
   line) protocol identifiers (proto values) for describing an SCTP
   association: 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'.  The section also
   describes how an m- line, associated with the proto values, is
created, and how the the media format (Œfmt¹) values are used."

----

>I'm glad we agree :-)

You only mentioned section 5.3, but I think the same applies also to
section 6.3 (MUX category for the max-message-size-attribute), so I
suggest to change both to CAUTION.

>This is probably a big enough change to make sure the workgroup also
>agrees, though.

*Sounds of crickets*

Yes, it does agree :)

 ----

>the vagueness of "MUST assume".

I suggest the following modified text:

"An SCTP endpoint SHOULD NOT send a SCTP user message with a message size
that is larger than the maximum size indicated by the peer. If the SCTP
endpoint needs (for whatever reason) to send a larger message, it cannot
be assumed that the message will be accepted by the peer.²

----

>> Roman had lots of input on this, so I'll let him reply.

See Roman¹s reply.

Regards,

Christer

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 24 Jan 2017 09:50:33 -0600

On 24 Jan 2017, at 7:20, Christer Holmberg wrote:

> Hi,
>
> ...
>
>
>>>> -4.1, last paragraph:
>>>> I assume this paragraph refers to fmt values used with 
>>>> UDP/DTLS/SCTP
>>>> or TCP/DTLS/SCTP,

The change helps, but does it still make sense if the last paragraph of 
4.1 moves to 4.3?

>>>> to the rules in the protocol definition. But the text here 
>>>> basically
>>>> say that the rules are undefined.
>>>

Ok, if no one objects before the IETF LC completes, we will assume 
agreement :-)

> be assumed that the message will be accepted by the peer.²

I'm okay with that, but don't be surprised if we get questions about 
whether it ever would ever make sense to send a message that you can't 
assume the peer will accept. (I wonder if it's more a matter of 
"probably not accept", given the peer has already stated its preference.

>>>> upper layers? Won't removal of the TCP connection or DTLS 
>>>> association
>>>> break

Thanks, I will reply there.

Ben.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Jan 2017 11:38:39 -0500

Roman,

On 1/23/17 8:16 PM, Roman Shpount wrote:
>
> On Mon, Jan 23, 2017 at 7:13 PM, Ben Campbell <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>             association break
> 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 can see that this can be a good thing when it is what you want/need.

OTOH, if one of the two parties involved changes, and there is no state 
sharing, you need to establish a new SCTP association. This may turn out 
to be the case even when the offerer doesn't know that the other party 
has changed.

So how are these two cases distinguished in the signaling? AFAICT the 
only thing available is sctp-port. If the offerer doesn't realize a 
change is coming, then it won't change its port. And in that case the 
answerer won't know what port its predecessor used, so it might choose 
the same value.

Of course, this is largely a 3pcc scenario, and if it is initiated in 
the middle then the middle can probably know to change the port somewhere.

But I'm not sure if that is the only case.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Jan 2017 11:41:09 -0500

>> This is probably a big enough change to make sure the workgroup also

This change seems good to me.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 Jan 2017 19:16:02 +0000

Hi,

>>>>> UDP/DTLS/SCTP or TCP/DTLS/SCTP, not fmt values in general.
>>>>
>>>> Correct.
>>>>
>>> I'm not sure all readers will see the connection between the first 
>>> and last paragraph. I still think it would help to explicitly mention 
>>> it.
>>> An alternative, if it were to stay in 4.1 would be to have the 
>>> opening paragraph in 4.1 explicitly mention that it includes the fmt 
>>> values to be used in the context of these new proto values.
>>>
>>>>
>>>>    "The m- line fmt value, identifying the application-layer 
>>>>    protocol, MUST be registered by IANA. Section 15.3 defines the IANA 
>>>>    registry for the media format namespace."
>>>>
>>>>

So, you suggest to not move the last paragraph to 4.3?

----

>>> That would be reasonable if it is the right answer. I just want to 
>>> avoid the vagueness of "MUST assume".
>>
>> "An SCTP endpoint SHOULD NOT send a SCTP user message with a message 
>> size that is larger than the maximum size indicated by the peer. If 
>> the SCTP endpoint needs (for whatever reason) to send a larger 
>> message, it cannot be assumed that the message will be accepted by the 
>> peer."
>
> I'm okay with that, but don't be surprised if we get questions about whether it ever would ever make
> sense to send a message that you can't assume the peer will accept. (I wonder if it's more a matter 
> of "probably not accept", given the peer has already stated its preference.

If nobody objects, I am ok saying "MUST NOT send".

Because, if there is a case where it would be needed, the peers simply need to support and negotiate a larger value.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 24 Jan 2017 14:18:42 -0500

On Tue, Jan 24, 2017 at 11:38 AM, Paul Kyzivat <[email-masked]>
wrote:

> sharing, you need to establish a new SCTP association. This may turn out to
> be the case even when the offerer doesn't know that the other party has
> changed.
>
> So how are these two cases distinguished in the signaling? AFAICT the only
> thing available is sctp-port. If the offerer doesn't realize a change is
> coming, then it won't change its port. And in that case the answerer won't
> know what port its predecessor used, so it might choose the same value.
>
> Of course, this is largely a 3pcc scenario, and if it is initiated in the
> middle then the middle can probably know to change the port somewhere.
>

We have considered that issue and assumed that selecting a random sctp-port
is sufficient to determine if this is the same vs new connection. There is
some possibility of collisions when answering party accidentally picks the
same port as the one which was previously used for SCTP communications, but
this is similar to ICE ufrag collisions, dtls-id collisions or to-tag
collisions. I do agree that sctp-port has less random bits then ufrag,
dtls-id, or to-tag, so it is more likely to collide. Please let us know if
this is a sufficient point of concern to warrant adding more randomness by
changing sctp-port definition (making it longer) or adding another
attribute. Another solution would be to require SCTP association restart on
DTLS association restart and use random bits in dtls-id minimize the chance
of collision.

In general, I am not strongly attached to not restarting SCTP association
on underlying transport change. I am even less attached to restarting SCTP
on DTLS restart.

What I do feel strongly about is:

1. Keeping SCTP association when ICE candidates change
2. Keeping SCTP association on ICE restart

Keeping SCTP association on ICE restart has exactly the same properties as
keeping SCTP association on transport change (it is unclear if ICE restart
was caused by the same endpoint or by endpoint change due to 3pcc). Since
ICE restart and transport change are essentially the same thing, I proposed
that SCTP association is preserved in both cases. If we tie SCTP
association restart to DTLS association restart we will get the desired
result for ICE only at the cost of loosing re-key ability for the existing
SCTP association.

So, my questions are:
1. Is possibility of sctp-port collision large enough concern to change
when SCTP association is restarted?
2. Would it be acceptable to lose ability to re-key DTLS association while
running the same SCTP assignations and force SCTP association restart on
DTLS association restart?

Regards,
_____________
Roman Shpount

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 24 Jan 2017 13:22:11 -0600

> So, you suggest to not move the last paragraph to 4.3?

No, my suggestion is to either (put the additional sentence in the first 
paragraph of 4.1 and keep last paragraph in 4.1) _OR_ (move the 
paragraph to 4.3 and put the clarification in _that_ paragraph.)

(Personally I like the latter, but either are okay.)

>
> ----
>
>
>>>>>> -6.1: What is meant by saying an "endpoint MUST assume that 
>>>>>> larger
>>>>>> ...
>>>>>> will be rejected"? Can that be stated in terms of actual 
>>>>>> procedure
>>>>>> (e.g.
>> whether it ever would ever make
> Because, if there is a case where it would be needed, the peers simply 
> need to support and negotiate a larger value.

Okay with me. If someone comes up with a plausible reason one might need 
to send larger messages, please speak up before the IETF LC completes. 
:-)

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 Jan 2017 20:04:18 +0000

Hi,

>>>>>>    "This section defines the following new SDP Media Description
>>>>>>      (m- line) protocol identifiers (proto values) for describing an 
>>>>>>      SCTP association: 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'."
>>>>>
>>>>> and last paragraph. I still think it would help to explicitly 
>>>>> mention it.
>>>>> opening paragraph in 4.1 explicitly mention that it includes the 
>>>>> fmt values to be used in the context of these new proto values.
>>>>>>
>>>>>>
>>>>>>    protocol, MUST be registered by IANA. Section 15.3 defines the 
>>>>>>    IANA registry for the media format namespace."
>>>>>>
>>>>>>
>>>>    association: 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'.  The section 
>>>>    also describes how an m- line, associated with the proto values, is
>>> The change helps, but does it still make sense if the last paragraph 
>>> of 4.1 moves to 4.3?
>>
> No, my suggestion is to either (put the additional sentence in the first paragraph of 4.1 and keep last
> paragraph in 4.1) _OR_ (move the paragraph to 4.3 and put the clarification in _that_ paragraph.)

Ok, so:

1) Don't modify the 1st paragraph in 4.1
2) Move the last paragraph to 4.3
3) Modify the paragraph in 4.3:

      "When the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values, 
        the m- line fmt value, identifying the application-layer
        rotocol, MUST be registered by IANA. Section 15.3 defines the  
        IANA registry for the media format namespace." 

----

>>>>>>> larger ...
>>>>>>> procedure (e.g.
>>>>>> I guess we could say SHOULD NO send larger message, and explain 
>>>>>> that one cannot assume that larger message (if sent for whatever
>>>>>> reason)
>>>> message, it cannot be assumed that the message will be accepted by 
>>>> the peer."
>>>
>>> whether it ever would ever make sense to send a message that you 
>>> can't assume the peer will accept.
>>> (I wonder if it's more a matter
> Okay with me. If someone comes up with a plausible reason one might need to send larger messages, please speak up before the IETF LC completes. :-)

Suggested modified paragraph:

         "An SCTP endpoint MUST NOT send a SCTP user message with a message 
          size that is larger than the maximum size indicated by the peer, as it 
          cannot be assumed that the peer would accept such message."

Regards,

Christer

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 24 Jan 2017 14:10:00 -0600

All looks good to me. Please submit a revision when you are ready, and I 
will request the IETF Last call.

Thanks!

Ben.

On 24 Jan 2017, at 14:04, Christer Holmberg wrote:

>> Okay with me. If someone comes up with a plausible reason one might 
>> need to send larger messages, please speak up before the IETF LC 
>> completes. :-)
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 Jan 2017 20:16:56 +0000

>All looks good to me. Please submit a revision when you are ready, and I will request >the IETF Last call.

I'll do it tomorrow. The other changes are on a local branch on my office computer.

Thanks!

Regards,

Christer

On 24 Jan 2017, at 14:04, Christer Holmberg wrote:

>>>>>> I'm not sure all readers will see the connection between the 
>>>>>> first and last paragraph. I still think it would help to 
>>>>>> explicitly mention it.
>>>> The change helps, but does it still make sense if the last 
>>>> paragraph of 4.1 moves to 4.3?
>>>
>> No, my suggestion is to either (put the additional sentence in the 
>> first paragraph of 4.1 and keep last paragraph in 4.1) _OR_ (move the 
>>>>>>> I'd like Roman's input on this, in case he had some cases in 
>>>>>>> mind where endpoint will have to send larger messages.
>>>>>>>
>>>>>> That would be reasonable if it is the right answer. I just want 
>>>>>> to avoid the vagueness of "MUST assume".
>>>>>
>>>>> "An SCTP endpoint SHOULD NOT send a SCTP user message with a 
>>>>> message size that is larger than the maximum size indicated by the 
>>>>> peer.
>>>>> If
>>>> I'm okay with that, but don't be surprised if we get questions 
>>>> about whether it ever would ever make sense to send a message that 
>>>> you can't assume the peer will accept.
>>> Because, if there is a case where it would be needed, the peers 
>>> simply need to support and negotiate a larger value.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Jan 2017 16:10:00 -0500

Roman,

On 1/24/17 2:18 PM, Roman Shpount wrote:

>     OTOH, if one of the two parties involved changes, and there is no
>     state sharing, you need to establish a new SCTP association. This
>     may turn out to be the case even when the offerer doesn't know that
>     the other party has changed.
>
>     So how are these two cases distinguished in the signaling? AFAICT
>     the only thing available is sctp-port. If the offerer doesn't
>     realize a change is coming, then it won't change its port. And in
>     that case the answerer won't know what port its predecessor used, so
>     it might choose the same value.
>
>     Of course, this is largely a 3pcc scenario, and if it is initiated
>     in the middle then the middle can probably know to change the port
>     somewhere.
>
> We have considered that issue and assumed that selecting a random
> sctp-port is sufficient to determine if this is the same vs new
> connection.

I see *no* mention that the sctp-port value should be chosen randomly. 
And IMO it is unnatural to suggest port values be random. There could be 
reasons for them not being random - for instance interop with SCTP over 
IP with well known ports. Also, while there is currently no spec for 
multiple SCTP associations in the same bundle, it is not hard to imagine 
that that might be a useful thing to do in the future. In that case 
random port numbers could be more troublesome.

> There is some possibility of collisions when answering party
> accidentally picks the same port as the one which was previously used
> for SCTP communications, but this is similar to ICE ufrag
> collisions, dtls-id collisions or to-tag collisions.

But those all use values that are specified to be random.

> I do agree that
> sctp-port has less random bits then ufrag, dtls-id, or to-tag, so it is
> more likely to collide. Please let us know if this is a sufficient point
> of concern to warrant adding more randomness by changing sctp-port
> definition (making it longer)

That isn't possible, because the port number and its format are 
specified in the SCTP spec.

> or adding another attribute. Another
> solution would be to require SCTP association restart on DTLS
> association restart and use random bits in dtls-id minimize the chance
> of collision.

The most straightforward way would be to follow the pattern used with 
comedia (rfv4145), with a=coonnection=new/existing. But that attribute 
couldn't be used, because it can already be in use for a TCP connection 
below it. Also, we have already abandoned using something akin to a=setup.

Unfortunately the end result we have arrived add is, IMO, a one-off hack 
that doesn't follow established approaches. This has arisen because we 
are negotiated layered protocols and the established SDP mechanisms 
don't have provision for that. But I don't think there is the will to 
clean this up.

> In general, I am not strongly attached to not restarting SCTP
> association on underlying transport change. I am even less attached to
> restarting SCTP on DTLS restart.

Coupling SCTP restart with one of those is a simple answer.

> Keeping SCTP association on ICE restart has exactly the same properties
> as keeping SCTP association on transport change (it is unclear if ICE
> restart was caused by the same endpoint or by endpoint change due to
> 3pcc). Since ICE restart and transport change are essentially the same
> thing, I proposed that SCTP association is preserved in both cases. If
> we tie SCTP association restart to DTLS association restart we will get
> the desired result for ICE only at the cost of loosing re-key ability
> for the existing SCTP association.
>
> So, my questions are:
> 2. Would it be acceptable to lose ability to re-key DTLS association
> while running the same SCTP assignations and force SCTP association
> restart on DTLS association restart?

I'd like to hear what others have to say.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Tue, 24 Jan 2017 17:02:39 -0500

> below it. Also, we have already abandoned using something akin to a=setup.

We have tried this approach with DTLS and we came to the conclusion that
a=connection:new/existing does not work in combination with 3pcc. This is
why we switched to dtls-id. So, two options that we have are to define
sctp-id or restart based on dtls-id.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Wed, 25 Jan 2017 12:52:18 -0500

One more clarification:

On Tue, Jan 24, 2017 at 4:10 PM, Paul Kyzivat <[email-masked]>
wrote:

> I see *no* mention that the sctp-port value should be chosen randomly. And
> IMO it is unnatural to suggest port values be random. There could be
> reasons for them not being random - for instance interop with SCTP over IP
> with well known ports. Also, while there is currently no spec for multiple
> SCTP associations in the same bundle, it is not hard to imagine that that
> might be a useful thing to do in the future. In that case random port
> numbers could be more troublesome.
>

SCTP associations described in this document are always simultaneous open
(active/active) associations. Because of this sctp-port values are
effectively emulating ephemeral ports allocated on the host system. Such
ports are randomly allocated. I do not think well known SCTP ports would
work with simultaneous open. This does not effect the ability to run
multiple SCTP associations over the same underlying transport, since all
this means that end point needs to allocate two different random sctp-port
values.

In any case, the option I was thinking about regarding sctp-port extension
is to modify it to add support for URL parameters and to be something like
a=sctp-port:6400;branch=abc3dl. The numeric part will be used in SCTP
packets and the branch parameter will be used to indicate new/existing
connection setup.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 Jan 2017 18:18:35 +0000

Hi,

>> I see *no* mention that the sctp-port value should be chosen randomly. And IMO it is unnatural to suggest port values
>> be random. There could be reasons for them not being random - for instance interop with SCTP over IP with well known 
>> ports. Also, while there is currently no spec for multiple SCTP associations in the same bundle, it is not hard to imagine 
>> that that might be a useful thing to do in the future. In that case random port numbers could be more troublesome.
>>
> SCTP associations described in this document are always simultaneous open (active/active) associations. Because of
> this sctp-port values are effectively emulating ephemeral ports allocated on the host system. Such ports are randomly
> allocated. I do not think well known SCTP ports would work with simultaneous open. This does not effect the ability 
> to run multiple SCTP associations over the same underlying transport, since all this means that end point needs to 
> allocate two different random sctp-port values.

Correct. The sctp-port attribute does not indicate an IP port.

> In any case, the option I was thinking about regarding sctp-port extension is to modify it to add support for URL 
> parameters and to be something like a=sctp-port:6400;branch=abc3dl. The numeric part will be used in SCTP packets 
> and the branch parameter will be used to indicate new/existing connection setup.

No. Let's not start making things complicated again. The document is in good shape in my opinion. Let's publish it.

Keep in mind that nothing prevents an endpoint from closing/re-opening an SCTP association at any time. All we are saying is that a DTLS change does not automatically affect the SCTP association. 

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Jan 2017 14:12:38 -0500

> Keep in mind that nothing prevents an endpoint from closing/re-opening an SCTP association at any time. All we are saying is that a DTLS change does not automatically affect the SCTP association.

I agree that if an endpoint explicitly initiates the closing of an SCTP 
association, and the other end acknowledges that, they can then 
establish a new association. (IIUC it would take another O/A to trigger 
establishing the new one.) But it requires one of the endpoints to know 
that this is needed.

Lets consider a 3pcc scenario, where A is in call with B via controller 
P, where P isn't proxying the media. Now suppose P wants to transfer the 
call, replacing B with C. Typically it will do this by sending an 
offerless invite to A, and then forward the resulting offer from A to C.

In this case C can't resume the SCTP association that A has with B. But 
A doesn't know that a new association is needed.

How can P resolve this?

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Wed, 25 Jan 2017 14:53:59 -0500

On Wed, Jan 25, 2017 at 2:12 PM, Paul Kyzivat <[email-masked]>
wrote:

> No. Let's not start making things complicated again. The document is in
>> good shape in my opinion. Let's publish it.
>>
>> Keep in mind that nothing prevents an endpoint from closing/re-opening an
>> SCTP association at any time. All we are saying is that a DTLS change does
>> not automatically affect the SCTP association.
>>
>
> association, and the other end acknowledges that, they can then establish a
> new association. (IIUC it would take another O/A to trigger establishing
> the new one.) But it requires one of the endpoints to know that this is
> needed.
>
> Lets consider a 3pcc scenario, where A is in call with B via controller P,
> where P isn't proxying the media. Now suppose P wants to transfer the call,
> replacing B with C. Typically it will do this by sending an offerless
> invite to A, and then forward the resulting offer from A to C.
>
> In this case C can't resume the SCTP association that A has with B. But A
> doesn't know that a new association is needed.
>
> How can P resolve this?
>

The assumption is that C will allocate a random sctp-port value. Since this
value is different then the sctp-port value previously allocated by B, A
will know this is a new SCTP association. C had no SCTP association, so it
will start new SCTP association as well. The only issue here is that C
accidentally allocates the same value as it was previously allocated by B.
We have 1/65,535 chance of this happening.

My question is: do you think the probably of collision is high enough that
this needs to be fixed?

For comparison, SIP to-tag which faces the same potential for collision
(SIP call forks and ends up on two end points. Bad things happen if both
terminating end points pick the same to-tag) and requires at least 32 bit
of crypto randomness.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 Jan 2017 19:54:33 +0000

Hi,

>> Keep in mind that nothing prevents an endpoint from closing/re-opening an SCTP association at any time. All 
>> we are saying is that a DTLS change does not automatically affect the SCTP association.
>
> I agree that if an endpoint explicitly initiates the closing of an SCTP association, and the other end acknowledges that, 
> they can then establish a new association. (IIUC it would take another O/A to trigger establishing the new one.) But it 
> requires one of the endpoints to know that this is needed.
>
> Lets consider a 3pcc scenario, where A is in call with B via controller P, where P isn't proxying the media. Now suppose P 
> wants to transfer the call, replacing B with C. Typically it will do this by sending an offerless invite to A, and then forward 
> the resulting offer from A to C.
>
> In this case C can't resume the SCTP association that A has with B. But A doesn't know that a new association is needed.

Assuming B terminates the SCTP association with A when the transfer occurs, A will know.

But, in any case, when C gets the offer, it will try to establish an SCTP association with A.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Jan 2017 15:08:38 -0500

On 1/25/17 2:53 PM, Roman Shpount wrote:
> On Wed, Jan 25, 2017 at 2:12 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>         No. Let's not start making things complicated again. The
>         document is in good shape in my opinion. Let's publish it.
>
>         Keep in mind that nothing prevents an endpoint from
>         closing/re-opening an SCTP association at any time. All we are
>         saying is that a DTLS change does not automatically affect the
>         SCTP association.
>
>
>     I agree that if an endpoint explicitly initiates the closing of an
>     SCTP association, and the other end acknowledges that, they can then
>     establish a new association. (IIUC it would take another O/A to
>     trigger establishing the new one.) But it requires one of the
>     endpoints to know that this is needed.
>
>     Lets consider a 3pcc scenario, where A is in call with B via
>     controller P, where P isn't proxying the media. Now suppose P wants
>     to transfer the call, replacing B with C. Typically it will do this
>     by sending an offerless invite to A, and then forward the resulting
>     offer from A to C.
>
>     In this case C can't resume the SCTP association that A has with B.
>     But A doesn't know that a new association is needed.
>
>     How can P resolve this?
>
>
> The assumption is that C will allocate a random sctp-port value. Since
> this value is different then the sctp-port value previously allocated by
> B, A will know this is a new SCTP association. C had no SCTP
> association, so it will start new SCTP association as well. The only
> issue here is that C accidentally allocates the same value as it was
> previously allocated by B. We have 1/65,535 chance of this happening.
>
> My question is: do you think the probably of collision is high enough
> that this needs to be fixed?

The chances are 1 in 2^16. That is high enough that it will happen 
regularly. Not everyone will encounter it, but there will be complaints 
- software will be accused of being "buggy".

It is hard to guess how objectionable this will be without digging 
deeper into what the implications will be. If the error is handled 
gracefully then it might not be a problem. I can't judge at the moment 
whether it will be straightforward to handle this gracefully.

	Thanks,
	Paul

> terminating end points pick the same to-tag) and requires at least 32
> bit of crypto randomness.
>
> Regards,
> _____________
> Roman Shpount
>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 25 Jan 2017 15:11:39 -0500

On Wed, Jan 25, 2017 at 2:54 PM, Christer Holmberg <
[email-masked]> wrote:

> association, and the other end acknowledges that,
> > they can then establish a new association. (IIUC it would take another
> O/A to trigger establishing the new one.) But it
> P, where P isn't proxying the media. Now suppose P
> > wants to transfer the call, replacing B with C. Typically it will do
> this by sending an offerless invite to A, and then forward
It does not quite works like this. In the described case, P first
establishes a session between A and B which has an SCTP session. Then P
sends an INVITE without SDP to A. A has no indication if new SCTP
association is needed, so it continues to use current SCTP association, and
sends an offer in the response to INVITE with SDP which contains current
sctp-port. P then sends the offer received from A to C. C had no SCTP
association running at that point, so it allocates new random sctp-port,
sends an answer to P and attempts to initiate an SCTP association with A. P
sends that answer to A, and if sctp-port in the answer is different A, will
know this is a new SCTP association and attempts to initiate an SCTP
association with C. If there is a random collision, A will think this is
the existing SCTP association, C will think this is a new SCTP association,
things break.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Jan 2017 15:13:08 -0500

> But, in any case, when C gets the offer, it will try to establish an SCTP association with A.

I agree that C will try that. I haven't done any digging into the 
details of the SCTP protocol, but it seems like A and C will be working 
at cross purposes. C will be trying to establish a new association, 
while A is trying to re-establish the existing SCTP association over a 
new DTLS association. Maybe it will just all work out, but I'm inclined 
to doubt it.

It would help to have a expert on the SCTP protocol chime in at this point.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 Jan 2017 20:21:09 +0000

Hi,

….

> It does not quite works like this. In the described case, P first establishes a session between A and B which has an SCTP session. Then P sends an INVITE without SDP to A. A > has no indication if new SCTP association is needed, so it continues to use current SCTP association, and sends an offer in the response to INVITE with SDP which contains 
> current sctp-port. P then sends the offer received from A to C. C had no SCTP association running at that point, so it allocates new random sctp-port, sends an answer to P > and attempts to initiate an SCTP association with A. P sends that answer to A, and if sctp-port in the answer is different A, will know this is a new SCTP association and 
> attempts to initiate an SCTP association with C. If there is a random collision, A will think this is the existing SCTP association, C will think this is a new SCTP association, 
> things break.

I think we can assume that the verification tag from C will be different, can't we? A will know that the INIT does not belong to the existing SCTP association.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Wed, 25 Jan 2017 15:24:12 -0500

On Wed, Jan 25, 2017 at 3:21 PM, Christer Holmberg <
[email-masked]> wrote:

> controller P, where P isn't proxying the media. Now suppose P
> sends an INVITE without SDP to A. A > has no indication if new SCTP
> sends an offer in the response to INVITE with SDP which contains
> > current sctp-port. P then sends the offer received from A to C. C had no
> SCTP association running at that point, so it allocates new random
> sctp-port, sends an answer to P > and attempts to initiate an SCTP
> association with A. P sends that answer to A, and if sctp-port in the
> answer is different A, will know this is a new SCTP association and
> > attempts to initiate an SCTP association with C. If there is a random
> collision, A will think this is the existing SCTP association, C will think
> this is a new SCTP association,
> > things break.
>
> I think we can assume that the verification tag from C will be different,
> can't we? A will know that the INIT does not belong to the existing SCTP
> association.
>

Upon checking with https://tools.ietf.org/html/rfc4960#section-5.2
establishing a new connection from C to A even before B have closed the
connection should work.

I would like somebody to double check this, but I think we can proceed with
the document as is.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 Jan 2017 20:26:19 +0000

Hi,

>>>> closing/re-opening an SCTP association at any time. All we are saying is that a DTLS change does not automatically affect the SCTP association.
>>>
>>> establish a new association. (IIUC it would take another O/A to trigger establishing the new one.) But it requires one of the endpoints to know that this is needed.
>>>
>>> to transfer the call, replacing B with C. Typically it will do this by sending an offerless invite to A, and then forward the resulting offer from A to C.
>>>
> I agree that C will try that. I haven't done any digging into the details of the SCTP protocol, but it seems like A and C will be working at cross purposes. C will be trying to 
> establish a new association, while A is trying to re-establish the existing SCTP association over a new DTLS association. Maybe it will just all work out, but I'm inclined to 
> doubt it.
>

We also of course have to assume that A, when it receives the offerless invite, creates an offer that represents the ongoing associations (including the currently used sctp-port value), and not a new one (if A offers a new sctp-port value, there won't be an issue, because the INIT from C will be received on that port). But, that is a general problem with 3pcc, not specific to SCTP.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Jan 2017 15:55:15 -0500

On 1/25/17 3:24 PM, Roman Shpount wrote:
> On Wed, Jan 25, 2017 at 3:21 PM, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     I think we can assume that the verification tag from C will be
>     different, can't we? A will know that the INIT does not belong to
>     the existing SCTP association.
>
>
> I would like somebody to double check this, but I think we can proceed
> with the document as is.

I don't understand SCTP sufficiently to sort out what will happen. But I 
do think we need to find out.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Jan 2017 15:57:53 -0500

> We also of course have to assume that A, when it receives the offerless invite, creates an offer that represents the ongoing associations (including the currently used sctp-port value), and not a n…

While (AFAIK) there are no SCTP-specific requirements pertaining to 
this, it is hard to imagine anyone concluding they should do otherwise.

	Thanks,
	Paul

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 25 Jan 2017 20:40:04 -0600

Hi,

Given the discussion, it seems to make sense to go ahead and start the 
IETF LC, and to ask for a TSV review team review as part of that. Does 
that make sense?

Thanks!

Ben.

On 25 Jan 2017, at 14:57, Paul Kyzivat wrote:

>>>>>> No. Let's not start making things complicated again. The document 
>>>>>> is in good shape in my opinion. Let's publish it.
>>>>>>
>>>>> wants
>>>>> to transfer the call, replacing B with C. Typically it will do 
>>>>> this by sending an offerless invite to A, and then forward the 
>>>>> resulting offer from A to C.
>>>>>
>>>>> In this case C can't resume the SCTP association that A has with 
>>>>> B. But A doesn't know that a new association is needed.
>>>>
>>> details of the SCTP protocol, but it seems like A and C will be 
>>> working at cross purposes. C will be trying to
>>> establish a new association, while A is trying to re-establish the 
>>> existing SCTP association over a new DTLS association. Maybe it will 
>>> just all work out, but I'm inclined to
>>> doubt it.
>>>
>> We also of course have to assume that A, when it receives the 
>> offerless invite, creates an offer that represents the ongoing 
>> associations (including the currently used sctp-port value), and not 
>> a new one (if A offers a new sctp-port value, there won't be an 
>> issue, because the INIT from C will be received on that port). But, 
>> that is a general problem with 3pcc, not specific to SCTP.
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 Jan 2017 08:02:10 +0000

Hi,

>IETF LC, and to ask for a TSV review team review as part of that. Does

Sounds good to me.

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 26 Jan 2017 00:29:41 -0800

In working through the ORTC SctpTransport implementation some of the oddities of SO became apparent. AFAICT existing implementations assume that the local and remote ports are the same and defaulting to 5000, which is funky. If one assumes that the remote port needs to be provided before an SCTP Association can be initiated, then does SO really make sense? The Answerer will have the Local and remote ports first, so it will initiate, but can the Offerer respond without receiving the Answer and the remote port?  This doesn't seem like active/active, really.

> On Jan 25, 2017, at 09:52, Roman Shpount <[email-masked]> wrote:
> 
> One more clarification:
> 
>> On Tue, Jan 24, 2017 at 4:10 PM, Paul Kyzivat <[email-masked]> wrote:
>> I see *no* mention that the sctp-port value should be chosen randomly. And IMO it is unnatural to suggest port values be random. There could be reasons for them not being random - for instance interop with SCTP over IP with well known ports. Also, while there is currently no spec for multiple SCTP associations in the same bundle, it is not hard to imagine that that might be a useful thing to do in the future. In that case random port numbers could be more troublesome.
> 
> SCTP associations described in this document are always simultaneous open (active/active) associations. Because of this sctp-port values are effectively emulating ephemeral ports allocated on the host system. Such ports are randomly allocated. I do not think well known SCTP ports would work with simultaneous open. This does not effect the ability to run multiple SCTP associations over the same underlying transport, since all this means that end point needs to allocate two different random sctp-port values.
> 
> In any case, the option I was thinking about regarding sctp-port extension is to modify it to add support for URL parameters and to be something like a=sctp-port:6400;branch=abc3dl. The numeric part will be used in SCTP packets and the branch parameter will be used to indicate new/existing connection setup.
> 
> Regards,
> _____________
> Roman Shpount
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 Jan 2017 08:39:01 +0000

Hi,

>In working through the ORTC SctpTransport implementation some of the oddities of SO became apparent. AFAICT existing implementations assume that the local and remote ports are the same and defaulting to 5000, which is funky. If
>one assumes that the remote port needs to be provided before an SCTP Association can be initiated, then does SO really make sense? The Answerer will have the Local and remote ports first, so it will initiate, but can the Offerer respond
>without receiving the Answer and the remote port?  This doesn't seem like active/active, really.

The offerer gets the port of the association initiated by the answerer in the INIT sent from the answerer. And, the spec says that the same ports must be used for both associations.

   "When an SCTP association is established, both SCTP endpoints MUST
   initiate the SCTP association (i.e. both SCTP endpoints take the
   'active' role), and MUST use the same SCTP port as client port and
   server port (in order to prevent two separate SCTP associations from
   being established)."

But, the offerer does need to get SOMETHING (the answer and/or the INIT) from the answerer before the offerer can initiate the association.

Regards,

Christer

One more clarification:

On Tue, Jan 24, 2017 at 4:10 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
I see *no* mention that the sctp-port value should be chosen randomly. And IMO it is unnatural to suggest port values be random. There could be reasons for them not being random - for instance interop with SCTP over IP with well known ports. Also, while there is currently no spec for multiple SCTP associations in the same bundle, it is not hard to imagine that that might be a useful thing to do in the future. In that case random port numbers could be more troublesome.

Regards,
_____________
Roman Shpount

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jan 2017 11:55:39 -0500

On 1/26/17 3:39 AM, Christer Holmberg wrote:
>>one assumes that the remote port needs to be provided before an SCTP
> Association can be initiated, then does SO really make sense? The
> Answerer will have the Local and remote ports first, so it will
> initiate, but can the Offerer respond
> The offerer gets the port of the association initiated by the answerer
> in the INIT sent from the answerer. And, the spec says that the same
> ports must be used for both associations.
>

I hadn't noticed that. Given that, section 10.3 ought to have normative 
language to that effect. Right now, all it says is:

    o  MUST associate an SDP 'sctp-port' attribute with the m- line.  If
       the offer contained a new (different than the one currently used)
       SCTP port value the answerer MUST also associate a new SCTP port
       value.  If the offer contained a zero SCTP port value, or if the
       answerer does not accept the SCTP association, the answerer MUST
       also associate a zero SCTP port value; and

Also, while this constraint is workable with UDP/DTLS/SCTP and 
TCP/DTLS/SCTP, it wouldn't be workable for SCTP directly over IP using 
well known ports for *either* end, because it would limit a given pair 
of IP addresses to one SCTP association per well known port. (SCTP ports 
9, 20,21,22 *have* been registered, so somebody thought they might be used.)

That isn't technically a problem now since the scope of the draft no 
longer includes SCTP over IP.

	Thanks,
	Paul

> But, the offerer does need to get SOMETHING (the answer and/or the INIT)
> from the answerer before the offerer can initiate the association.
>
> Regards,
>
> Christer
>
>
>
>
>> One more clarification:
>>
>> On Tue, Jan 24, 2017 at 4:10 PM, Paul Kyzivat
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     I see *no* mention that the sctp-port value should be chosen
>>     randomly. And IMO it is unnatural to suggest port values be
>>     random. There could be reasons for them not being random - for
>>     instance interop with SCTP over IP with well known ports. Also,
>>     while there is currently no spec for multiple SCTP associations in
>>     the same bundle, it is not hard to imagine that that might be a
>>     useful thing to do in the future. In that case random port numbers
>>     could be more troublesome.
>>
>>
>> SCTP associations described in this document are always simultaneous
>> open (active/active) associations. Because of this sctp-port values
>> are effectively emulating ephemeral ports allocated on the host
>> system. Such ports are randomly allocated. I do not think well known
>> SCTP ports would work with simultaneous open. This does not effect the
>> ability to run multiple SCTP associations over the same underlying
>> transport, since all this means that end point needs to allocate two
>> different random sctp-port values.
>>
>> In any case, the option I was thinking about regarding sctp-port
>> extension is to modify it to add support for URL parameters and to be
>> something like a=sctp-port:6400;branch=abc3dl. The numeric part will
>> be used in SCTP packets and the branch parameter will be used to
>> indicate new/existing connection setup.
>>
>> Regards,
>> _____________
>> Roman Shpount
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 Jan 2017 17:24:24 +0000

Hi,

>>>In working through the ORTC SctpTransport implementation some of the 
>>>oddities of SO became apparent. AFAICT existing implementations assume 
>>>that the local and remote ports are the same and defaulting to 5000, 
>>>which is funky. If one assumes that the remote port needs to be 
>>>provided before an SCTP
> I hadn't noticed that. Given that, section 10.3 ought to have normative language to that effect. Right now, all it says is:
>

Section 10.3 is about the offer/answer procedures, including assigning the sctp-port value, while the other text is related to the SCTP establishment.

>Also, while this constraint is workable with UDP/DTLS/SCTP and TCP/DTLS/SCTP, it wouldn't be workable for SCTP directly over IP using well known ports for *either* end, >because it would limit a given pair of IP addresses to one SCTP association per well known port. (SCTP ports 9, 20,21,22 *have* been registered, so somebody thought they >might be used.)
>
>That isn't technically a problem now since the scope of the draft no longer includes SCTP over IP.

Correct. 

Regards,

Christer

> But, the offerer does need to get SOMETHING (the answer and/or the 
> INIT) from the answerer before the offerer can initiate the association.
>
> Regards,
>
> Christer
>
>
>
>
>> One more clarification:
>>
>> SCTP ports would work with simultaneous open. This does not effect 
>> the ability to run multiple SCTP associations over the same 
>> underlying transport, since all this means that end point needs to

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jan 2017 12:54:27 -0500

> Section 10.3 is about the offer/answer procedures, including assigning the sctp-port value, while the other text is related to the SCTP establishment.

Yes, but they need to be consistent. As currently written, it would be 
valid for the answerer to include a different sctp-port value in the 
answer, as long as it then ignores that and uses the value from the 
offer in the protocol.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Thu, 26 Jan 2017 13:03:29 -0500

On Thu, Jan 26, 2017 at 3:39 AM, Christer Holmberg <
[email-masked]> wrote:

> oddities of SO became apparent. AFAICT existing implementations assume that
> the local and remote ports are the same and defaulting to 5000, which is
> funky. If
> Association can be initiated, then does SO really make sense? The Answerer
> will have the Local and remote ports first, so it will initiate, but can
> the Offerer respond
> The offerer gets the port of the association initiated by the answerer in
> the INIT sent from the answerer. And, the spec says that the same ports
> must be used for both associations.
>
I just wanted to double check, is everyone sure that SCTP client and server
ports MUST be the same? If this is the case, sctp-port cannot be used to
indicate that new SCTP association should be established. We need some
additional indicate to signal this.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 Jan 2017 18:17:27 +0000

Hi,

>>>>> In working through the ORTC SctpTransport implementation some of 
>>>>> the oddities of SO became apparent. AFAICT existing implementations 
>>>>> assume that the local and remote ports are the same and defaulting 
>>>>> to 5000, which is funky. If one assumes that the remote port needs 
>>>>> to be provided before an SCTP
>>>> initiate, but can the Offerer respond without receiving the Answer 
>>>> and the remote port?  This doesn't seem like active/active, really.
>>>>
>>>> The offerer gets the port of the association initiated by the 
>>>> answerer in the INIT sent from the answerer. And, the spec says that 
>>>> the same ports must be used for both associations.
>>>>
> Yes, but they need to be consistent. As currently written, it would be valid for the answerer to include a different sctp-port value in the answer, as long as it then ignores 
> that and uses the value from the offer in the protocol.

It IS valid for the answerer the include a different sctp-port value.

What the text means is that and endpoint needs to use the same local port for sending and receiving SCTP messages. But, both endpoints don't need to use the same port value.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 Jan 2017 18:19:24 +0000

Hi,

The text means that each endpoint must send and receive SCTP messages on the same local port. It does NOT mean that each endpoint must assign the same sctp-port value.

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 26 January 2017 20:03
To: Christer Holmberg <[email-masked]>
Cc: Bernard Aboba <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments

On Thu, Jan 26, 2017 at 3:39 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

   being established)."

I just wanted to double check, is everyone sure that SCTP client and server ports MUST be the same? If this is the case, sctp-port cannot be used to indicate that new SCTP association should be established. We need some additional indicate to signal this.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jan 2017 13:53:57 -0500

> What the text means is that and endpoint needs to use the same local port for sending and receiving SCTP messages. But, both endpoints don't need to use the same port value.

You mean symmetric use of the sctp-port values?

For instance, if A offers sctp-port:5000 and B offers sctp-port:6000, 
then messages sent from A to B must have 5000 as the from-port and 6000 
as the to-port; and messages sent from B to A must have 6000 as the 
from-port and 5000 as the to-port.

Given that was your point, lets go back to what you said that triggered 

> But, the offerer does need to get SOMETHING (the answer and/or the INIT) from the answerer before the offerer can initiate the association.

You are assuming here that there is only one SCTP association at a time 
over the lower layer (in this case DTLS). If there might be more than 
one such association then the offerer can't assume that the port number 
in the incoming INIT pertains to *this* association. After all, the 
*point* of port numbers is to demux sessions over the lower layer.

Now this is a valid as long as multiple SCTP associations aren't bundled 
over the same DTLS UDP/TCP ports. Since doing such bundling is 
*currently* undefined, it can work for now. But it would make perfect 
sense to define bundlilng of multiple SCTP associations, using the 
sctp-port values for the demuxing. So in my opinion we ought not be 
spelling out procedures for SCTP association establishment that only 
work in this limited case. Hence it should be presumed that the offerer 
can't initiate the SCTP association until it receives the answer.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 Jan 2017 19:11:36 +0000

Hi,

>>>>>>> the oddities of SO became apparent. AFAICT existing 
>>>>>>> implementations assume that the local and remote ports are the 
>>>>>>> same and defaulting to 5000, which is funky. If one assumes that 
>>>>>>> the remote port needs to be provided before an SCTP
>>>>>> answerer in the INIT sent from the answerer. And, the spec says 
>>>>>> that the same ports must be used for both associations.
>>>>>>
>>> Yes, but they need to be consistent. As currently written, it would 
>>> be valid for the answerer to include a different sctp-port value in the answer, as long as it then ignores that and uses the value from the offer in the protocol.
>>

Correct.

> For instance, if A offers sctp-port:5000 and B offers sctp-port:6000, then messages sent from A to B must 
> have 5000 as the from-port and 6000 as the to-port; and messages sent from B to A must have 6000 as the from-port and 5000 as the to-port.

Yes.

> Given that was your point, lets go back to what you said that triggered this part of the thread:
>
> The offerer gets the port of the association initiated by the answerer in the INIT sent from the 
> answerer. And, the spec says that the same ports must be used for both associations.
>
> You are assuming here that there is only one SCTP association at a time over the lower layer (in this case DTLS). If there 
> might be more than one such association then the offerer can't assume that the port number in the incoming INIT pertains 
> to *this* association. After all, the *point* of port numbers is to demux sessions over the lower layer.
>
> Now this is a valid as long as multiple SCTP associations aren't bundled over the same DTLS UDP/TCP ports. Since doing 
> such bundling is *currently* undefined, it can work for now. But it would make perfect sense to define bundlilng of multiple 
> SCTP associations, using the sctp-port values for the demuxing. So in my opinion we ought not be spelling out procedures for 
> SCTP association establishment that only work in this limited case. Hence it should be presumed that the offerer can't initiate 
> the SCTP association until it receives the answer.

We are assuming a single SCTP association, and that is also documented in the draft. Section 7 says:

   "NOTE: While [I-D.ietf-tsvwg-sctp-dtls-encaps] allows multiple SCTP
   associations on top of a single DTLS association, the procedures in
   this specification only support the negotiation of a single SCTP
   association on top of any given DTLS association."

I do not think this is the time to change that assumption. 

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jan 2017 14:29:27 -0500

> I do not think this is the time to change that assumption.

I'm not advocating changing that assumption, I don't think we should 
make decisions that preclude relaxing it in the future.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 Jan 2017 19:38:10 +0000

Hi,

...

> I'm not advocating changing that assumption, I don't think we should make decisions that preclude relaxing it in the future.

If there is a need in the future, we'll deal with it. That may include some kind of I-support-multiple-associations indicator, and procedures associated with that.

The only customer (that I am aware of) of this document is WebRTC, and with QUIC on the horizon I am not sure there will be too many others (but, if there will be, we'll deal with it).

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jan 2017 14:59:26 -0500

> The only customer (that I am aware of) of this document is WebRTC, and with QUIC on the horizon I am not sure there will be too many others (but, if there will be, we'll deal with it).

In that case there is no need to negotiate sctp-port at all. It has 
ceased to mean anything like what it is intended to mean within the 
definition of SCTP. Pretending that we are negotiating it simply leads 
to confusion. Rather, what has been done is to agree to ignore the prt 
number as a mechanism for demultiplexing and repurpose the field in the 
protocol to carry a "establish new association" indicator.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 Jan 2017 20:12:16 +0000

Hi,

...

>> The only customer (that I am aware of) of this document is WebRTC, and with QUIC on the horizon I am not sure there will be 
>> too many others (but, if there will be, we'll deal with it).
>
> In that case there is no need to negotiate sctp-port at all. It has ceased to mean anything like what it is intended to mean within the
> definition of SCTP. Pretending that we are negotiating it simply leads to confusion. Rather, what has been done is to agree to ignore
> the prt number as a mechanism for demultiplexing and repurpose the field in the protocol to carry a "establish new association" indicator.

The endpoints still need to know the port of the peer - even if they are only going to initiate a single association.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jan 2017 15:35:29 -0500

> The endpoints still need to know the port of the peer - even if they are only going to initiate a single association.

But, IIUC, *you* were suggesting that the offerer might discover the 
port from a received INIT message rather than waiting for the answer. 
*That* only works if the answerer only has one association at a time.

As long as the offerer waits to get the sctp-port from the answer before 
sending any SCTP messages to the offerer.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 Jan 2017 20:46:36 +0000

Hi,

>>> definition of SCTP. Pretending that we are negotiating it simply leads to confusion. Rather, what has been done is to agree to ignore the prt number as a mechanism for >>> demultiplexing and repurpose the field in the protocol to carry a "establish new association" indicator.
>>
> But, IIUC, *you* were suggesting that the offerer might discover the port from a received INIT message rather than waiting for the answer. 

Yes. But, if the offerer for whatever reason receives the answer before the INIT, it allows the offerer to send its INIT.

> *That* only works if the answerer only has one association at a time.

Correct. If we in future define support for multiple associations that won't be enough. Perhaps we then need to signal multiple ports, and/or consider e.g., the SCTP association ID too, etc etc etc. 

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jan 2017 16:01:37 -0500

> Correct. If we in future define support for multiple associations that won't be enough. Perhaps we then need to signal multiple ports, and/or consider e.g., the SCTP association ID too, etc etc etc.

In any case, this is mostly moot, because you need the IP address and 
UDP port before you can start to establish the association, and those 
also come in the answer. (Or from ICE after having received some 
candidates in the answer.)

I guess the time when it might apply is when adding the SCTP to a 
preexisting bundle, and requiring it to be bundle-only.

I guess if somebody wants to build an optimization based on all the 
necessary special cases applying then that is their business. But I 
wouldn't like to see that written down in the specs.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 Jan 2017 22:37:47 +0000

Hi,

You can add an SCTP association to an existing DTLS association, that has earlier been established e.g., for audio and video.

Regards,

Christer

Sent from my iPhone

> On 26 Jan 2017, at 23.01, Paul Kyzivat <[email-masked]> wrote:
> 
> In any case, this is mostly moot, because you need the IP address and UDP port before you can start to establish the association, and those also come in the answer. (Or from ICE after having received some candidates in the answer.)
> 
> I guess the time when it might apply is when adding the SCTP to a preexisting bundle, and requiring it to be bundle-only.
> 
> I guess if somebody wants to build an optimization based on all the necessary special cases applying then that is their business. But I wouldn't like to see that written down in the specs.
> 
>    Thanks,
>    Paul
>

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 26 Jan 2017 17:27:39 -0600

Hi,

I just requested the IETF last call on version 22. And then I noticed a 
bunch of conversation popped up today that I hadn't seen yet. Based on a 
quick scan, I think it is reasonable to go ahead with the IETF LC, and 
if any changes result from the ongoing conversation, they can be 
addressed as part of the LC.

If anyone feels strongly otherwise, let me know and I can cancel the LC.

Thanks!

Ben.

On 26 Jan 2017, at 2:02, Christer Holmberg wrote:

>>>>>>>> document
>>>>>> Assuming B terminates the SCTP association with A when the 
>>>>>> transfer
>>>>>> occurs, A will know.
>>>>>>
>>>>> It would help to have a expert on the SCTP protocol chime in at 
>>>>> this
>>>>> point.
>>>>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 Jan 2017 03:46:24 +0000

Hi,

I think we can move ahead. Then, if the transport people find issues, we may have to come back.

Regards,

Christer 

Sent from my iPhone

> On 27 Jan 2017, at 1.27, Ben Campbell <[email-masked]> wrote:
> 
> Hi,
> 
> I just requested the IETF last call on version 22. And then I noticed a bunch of conversation popped up today that I hadn't seen yet. Based on a quick scan, I think it is reasonable to go ahead with the IETF LC, and if any changes result from the ongoing conversation, they can be addressed as part of the LC.
>