Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sctp-sdp-08 - Paul's comments

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Dec 2014 08:49:14 +0000

Hi Paul,

Thanks for your comments! Reply inline.

> Section 4.3:
>
> Using MIME subtypes on the m-line doesn't really work well. The value doesn't really define a data format - it defines a discipline for choosing and using stream 
> ids, and possibly a format for each one. I think that all of the first paragraph should be deleted, with the exception of the first sentence.

I can do that, if no one else have an issue doing so.

-------------

> Section 5.1:
>
> IMO 5000 is a bad choice for the default port value. It falls in the middle of the registered port list. It isn't currently 
> registered (I don't know why) but it potentially could. I suggest that a number outside of the registered port range 
> (>49151) would be safest. To avoid being arbitrary, I suggest 65535 - the largest possible 16 bit number.

I have no problem to change the default value.

However, 5000 was defined before I got involved with the draft, so I think it would be good to get some input from Gonzalo and/or Salvatore whether there was some specific reason for 5000.

-------------

> Section 6.2:
>
> I don't understand why sctpmap-attr is defined, since it isn't referenced anywhere. I think it is a holdover from when there was an sctpmap attribute.

Correct, that is a mistake.

The purpose of Section 6.2 is to define the format of the SDM fmtp attribute when used with SCTP.

> It seems that what is being done here is to define the syntax of a=fmtp for all fmt values that might be used with sctp. I don't think that is kosher. 
> I think fmtp needs to be defined for webrtc-datachannel, and again for each other application-usage that wants to use it.
>
> It is unpleasant to expect all application-usages to do this. But the alternative is to go back to defining a special attribute for max-message-size. Perhaps:
>
>      Attribute name: sctp-attr
>      Attribute value: sctp-attr-value
>      Attribute Syntax:
>
>      sctp-attr-value = association-usage [max-message-size]
>      max-message-size  =  "max-message-size" EQUALS 1*DIGIT

If we decide to have a special attribute, why not simply call it "a=max-message-size"?

We only allow a single association-usage per m- line, so there is no need to explicitly map the fmt value to a specific sctp-attr attribute.

      Attribute name: sctp-max-message-size	(We can use a shorter name)
      Attribute value: max-message-size
      Attribute Syntax:

      sctp-max-message-size = max-message-size
      max-message-size  =  1*DIGIT

-------------

> Section 8:
>
> I think something probably needs to be said about sendonly/recvonly/inactive. I'm not sure what. Maybe they shouldn't be used at all. Or maybe they can make some sort of sense.

I was thinking about the same thing, but left it out of this version on purpose (I should have added an open issue regarding it, though).

I see no reason why we couldn't use sendonly/recvonly/inactive also for SCTP - assuming it only impacts what is sent on the SCTP association. I.e. it would not impact the DTLS connection, and whatever (UDP or TCP) is below DTLS.

-------------

> Section 9:
>
> The NOTE seems inadequate. If SCTP is being used in an environment that does gating based on SDP, then multihoming probably won't work. None of the negotiated alternative addresses will get their gates opened. So maybe more needs to be said about this.

So, you don't think the existing text is wrong - you just think we need more text, right?

-------------

> Section 10.1:
>
> The last paragraph about NATs references RFC6951. Wouldn't it be clearer if it simply referenced DTLS/SCTP defined in this draft?

I can look into that.

-------------

> Section 10.2:
>
> This isn't quite true is it? ICE is defined to work over DTLS/SCTP. 
>
> While the emphasis is on those cases where the SCTP is bundled with SRTP, it should work just fine without bundle.

Ok, I guess the text should be more clear, and talk about "pure" SCTP and SCTP/DTLS.

Regards,

Christer

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 2 Dec 2014 12:00:46 +0000

Hi there,

> However, 5000 was defined before I got involved with the draft, so I think it would be good to get some input from Gonzalo and/or Salvatore whether there was some specific reason for 5000.

5000 is the default value the current/available SCTP over TLS are using.

br
/Salvatore

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Dec 2014 12:11:54 +0000

Hi,

>>> Section 5.1:
>>> 
>>> IMO 5000 is a bad choice for the default port value. It falls in the 
>>> middle of the registered port list. It isn't currently registered (I 
>>> don't know why) but it potentially could. I suggest that a number 
>>> outside of the registered port range

Thanks for the information, Sal!

I guess we in the SCTP-SDP draft could refer to the SCTPoDTLS spec, to clarify where the value comes from.

Regards,

Christer

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 2 Dec 2014 13:22:48 +0000

> 5000 is the default value the current/available SCTP over TLS are using.

just to clarify
what I meant is that 5000 is the value that as far as I know Firefox is using in its SCTP over TLS data channel implementation

br
Salvatore

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Dec 2014 11:02:34 -0500

> what I meant is that 5000 is the value that as far as I know Firefox is using in its SCTP over TLS data channel implementation

AFAIK it is being explicitly specified as 5000, not that there is 
reliance on a default value of 5000. Changing the default only affects 
those implementations depending on the default.

Also, if those implementations are using different SDP syntax, not 
conformant with this version of the draft, then they will need to be 
changed anyway before this change becomes effective.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Dec 2014 11:15:05 -0500

> I can do that, if no one else have an issue doing so.

That would work too, if we expect that there will only ever be the one 
sctp-association-wide property to specify.

My question is: what does it mean? (Given that there are multiple 
streams, and from an SCTP perspective the streams are unidirectional.) 
Some issues:

- If someone is using channels, and the protocol over a channel requires 
ACKs, is it restricted to sendrecv?

- Does it make sense to change the directionality of all the channels in 
parallel?

Also, there is the option of using the direction attributes on a 
per-channel basis via a=dcsa.

Maybe it makes the most sense, for now at least, to specify that the 
directionality attributes have no defined meaning in conjunction with an 
SCTP association.

Right.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Dec 2014 17:09:31 +0000

Hi,

> That would work too, if we expect that there will only ever be the one sctp-association-wide property to specify.

Well, if we want to specify max message size e.g. per SCTP stream, then we'd need something else. But, I don't think anyone has asked for that?

-------------

>>> Section 8:
>>>
>>> I think something probably needs to be said about sendonly/recvonly/inactive. I'm not sure what. Maybe
>>> they shouldn't be used at all. Or maybe they can make some sort of sense.
>>
>> I see no reason why we couldn't use sendonly/recvonly/inactive also for SCTP - assuming it only impacts 
>> what is sent on the SCTP association. I.e. it would not impact the DTLS connection, and whatever (UDP or TCP) is below DTLS.
>
> My question is: what does it mean? (Given that there are multiple streams, and from an SCTP perspective the streams are unidirectional.) Some issues:
>
> - If someone is using channels, and the protocol over a channel requires ACKs, is it restricted to sendrecv?
>
> - Does it make sense to change the directionality of all the channels in parallel?

Well, it depends on for what you are using the SCTP association.

For example, if you would send RTP over SCTP, I guess you could use sendonly/recvonly in the same way as you do for UDP.

If you implement data channels, then sendonly/recvonly would probably cause problem in most cases. It's similar to the case where consent to send expires in one direction :)

> Also, there is the option of using the direction attributes on a per-channel basis via a=dcsa.

I think such direction would have to be a subset of the SCTP association wide value. 

> Maybe it makes the most sense, for now at least, to specify that the directionality attributes have no defined meaning in conjunction with an SCTP association.

What if someone wants to use SCTP with preconditions?

Alternatively, we recommend against using non-sendrecv, unless one is absolutely sure it won't cause problems.

IF used, it applies to the whole SCTP association, including all SCTP stresms etc.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Dec 2014 12:37:37 -0500

> Well, if we want to specify max message size e.g. per SCTP stream, then we'd need something else. But, I don't think anyone has asked for that?

OK. I'm fine with a max-message-size attribute.
Define it only for SCTP, but maybe others might choose to define it for 
other protocols in the future.

> For example, if you would send RTP over SCTP, I guess you could use sendonly/recvonly in the same way as you do for UDP.

Sending RTP over SCTP opens up a new set of questions:
- which stream(s) are used?
- is RTCP sent on a different stream from RTP?
   (I guess it would be a good idea.)

Note that with RTP a=inactive applies to the RTP but not the RTCP.

All those questions need to be figured out again for RTP over SCTP.
And we had that discussion. People could find no benefit to RTP over 
SCTP, compared to SRTP over DTLS/SCTP.

Also note that sendrecv doesn't really make sense for SCTP *streams*, 
since they are all unidirectional. It does make sense over 
webrtc-datachannels, but that is a special case of SCTP.

> If you implement data channels, then sendonly/recvonly would probably cause problem in most cases. It's similar to the case where consent to send expires in one direction :)

It may make sense for certain protocols over the channels, but not others.

> I think such direction would have to be a subset of the SCTP association wide value.

I suppose we could view an association-wide value to be a default for a 
per-channel value. But again it only makes sense when channels are in use.

> What if someone wants to use SCTP with preconditions?

Another can of worms. What do you want to prevent while negotiating 
preconditions? (E.g., do you want to block use of ICE until the 
preconditions are resolved?)

> Alternatively, we recommend against using non-sendrecv, unless one is absolutely sure it won't cause problems.

Without a definition of what it *means*, one can't be sure of anything.

If we are to define the meaning, then I guess
- sendonly: can send on outgoing streams (any ID), don't want to
   receive on any streams. (But what do you do if something still
   arrives on a stream?)
- recvonly: want to receive on incoming streams, will not send on
   any stream.
- inactive: will not send on any stream, don't want to receive on
   any stream.

This is at the SCTP level. Since DCEP uses messages on streams, this 
means you can't establish new channels on an inactive association.

I'm not sure about stream reset. Can it be sent on inactive or recvonly 
streams?

Whatever the right answers are, they need to be defined.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Dec 2014 08:14:19 +0000

Hi,

> Define it only for SCTP, but maybe others might choose to define it for other protocols in the future.

We could add text saying that the sctp-sdp draft only defines usag of the attribute for SCTP, SCTP/DTLS and DTLS/SCTP, and that usage with other proto values need to be specified.

-------------

>>>>> Section 8:

...

First, I didn't suggest that we'd define RTP over SCTP. I only used RTP as an example where sendonly/recvonly/inactive is useful.

But, I DO hear what you are saying. I was checking RFC 4566 and 3264, and they are not very clear either. RFC 4566 does define the RTP/RTCP impacts, so it seems it has to be done case by case.

So, I guess we could specify that the usage has to be defined per SCTP association usage.

Then, the question is whether we want to define the usage for webrtc-datachannels. We could do that either in the SCTP-SDP draft, or somewhere else - e.g. in Keith Richard's draft.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Dec 2014 12:25:53 +0000

Hi,

> We could add text saying that the sctp-sdp draft only defines usag of the attribute for SCTP, SCTP/DTLS and DTLS/SCTP, and that usage with other proto values need to be specified.

Suggested text:

-------------

6.  SDP 'max-message-size' Attribute

6.1.  General

   The SDP 'max-message-size' attribute can be associated with an m-
   line to indicate the maximum message size that an SCTP endpoint is
   willing to receive on the SCTP association associated with the m-
   line.

   The remote peer MUST assume that larger messages will be rejected by
   the SCTP endpoint.  SCTP endpoints need to decide on appropriate
   behaviour in case a message that exceeds the maximum size needs to be
   sent.

   If the SDP 'max-message-size' attribute contains a maximum message
   size value of zero, it indicates the SCTP endpoint will handle
   messages of any size, subject to memory capacity etc.

   If the SDP 'max-message-size' attribute is not present, the default
   value is 64K.

6.2.  Syntax

       max-message-size-attr =  "a=max-message-size:" max-message-size
       max-message-size      =  1*DIGIT

-------------

> Then, the question is whether we want to define the usage for webrtc-datachannels. We could do that either in the SCTP-SDP draft, or somewhere else - e.g. in Keith Richard's draft.

Suggested text:

-------------

8.2.  SDP sendrecv/sendonly/sendrecv/inactive Attribute

   This specification does not define usage of the SDP direction
   attributes.  Specifications for an individual SCTP association usage
   MAY define how the attributes can be used with that usage.  If usage
   for a SCTP association usage has not be defined, SDP direction
   attributes MUST be discarded if present.

-------------

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 03 Dec 2014 13:56:41 +0100

>     attributes MUST be discarded if present.

Looks good to me, but you might want to avoid using "usage" twice with 
different meanings in the same sentence.

What about:

    This specification does not define any meaning for the SDP direction
    attributes.  Specifications for an individual SCTP association usage
    MAY define how the attributes can be used with that usage.  If the meaning
    of these attributes for a SCTP association usage has not been defined, SDP direction
    attributes MUST be discarded if present.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Dec 2014 13:55:34 +0000

Hi Harald,

You suggested text looks good, but perhaps "semantics" instead of "meaning"? 

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: 3. joulukuuta 2014 14:57
To: [email-masked]
Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sctp-sdp-08 - Paul's comments

>     attributes MUST be discarded if present.

Looks good to me, but you might want to avoid using "usage" twice with different meanings in the same sentence.

What about:

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

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 03 Dec 2014 15:18:07 +0100

> You suggested text looks good, but perhaps "semantics" instead of "meaning"?

"semantics" is probably good. "meaning" brings out the epistomologists.....

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Dec 2014 10:01:25 -0500

WFM