Subject: Re: [MMUSIC] Should we put the SCTP max message size in the SDP?

From: Salvatore Loreto <[email-masked]>
Date: Sat, 23 Nov 2013 14:51:48 +0000

(adding mmusic mailing list, sorry for cross posting but if we want to progress the draft
within IETF we have to discuss it in the mmusic mailing list)

the http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-05
still allow to specify the number of streams, even if it is optional

if we want to add also max-message-size attribute, also as on optional one
what about something like this?

a=sctpmap:5000 webrtc-datachannel [streams] [max-message-size]

/Salvatore

On Nov 23, 2013, at 1:35 AM, Peter Thatcher <[email-masked]<mailto:[email-masked]>>
 wrote:

On Fri, Nov 22, 2013 at 3:31 PM, Michael Tuexen <[email-masked]<mailto:[email-masked]>> wrote:
On Nov 23, 2013, at 12:16 AM, Peter Thatcher <[email-masked]<mailto:[email-masked]>> wrote:

> Yes, we agreed to forego putting streams in the SDP.  I'm sure I got the syntax of the SDP wrong.  Yours looks better.
and the semantic is: I'm willing to accept SCTP user messages of at least 1000000 bytes, right?

​Correct.​

It makes sense to put it into the SDP...

Best regards
Michael
>
>
> On Fri, Nov 22, 2013 at 2:51 PM, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:
> I like the idea, but I'm not sure the syntax in http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-04 can express this.
>
> The current a=sctpmap is
>
> a=sctpmap:5000 webrtc-datachannel [streams]
>
> although IIRC we agreed to forego the whole streams negotiation thing.
>
> So we would need something like a=fmtp:5000 max-message-size=1000000.
>
>
> On Fri, Nov 22, 2013 at 2:28 PM, Peter Thatcher <[email-masked]<mailto:[email-masked]>> wrote:
> This is probably going to sound strange coming from me, but I think it might be a better idea to put the SCTP max message size in the SDP.
>
> I'm still OK with having an in-band message (as we discussed during TPAC) to swap the SCTP max message between endpoints, but I was thinking about it a little more and realized that it does involve some extra edge cases and a bit of possible latency.  It would be nice if we could do a handshake earlier on.... and then I realized we can because we can just put it in the SDP where we already do a handshake well ahead of time.
>
> Something like:
>
> a=sctpmap:5000 max-message-size 1000000
>
>
> Obviously I'm not a big fan of stuffing lots of stuff into SDP, but I think this is very minimal and is a more simple solution.
>
>
>
>
> What do you think?
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 23 Nov 2013 13:32:51 -0800

On Sat, Nov 23, 2013 at 7:19 AM, Michael Tuexen <
[email-masked]> wrote:

> On Nov 23, 2013, at 3:51 PM, Salvatore Loreto <
> [email-masked]> wrote:
>
> >
> ... and what is the semantic if max-message-size is not provided? The
> endpoint
> is willing to accept arbitrary large messages?
>
> I also suggest to rename max-message-size to supported-message-size.
> The semantics is that the end-point is willing to accept messages up to
> supported-message-size. It does not make a statement about messages larger
> than the limit. Calling it max-message-size suggests to me, that messages
> larger than the limit can't be handled...

1. I'm cool with the idea of negotiating this in the SDP.
2. I actually think it would be better to have a max message size, since
otherwise we're back in the indeterminate behavior case.
3. The semantics should be that each side just gets to inform the other
side of their value, not that it's negotiated.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Sat, 23 Nov 2013 14:54:18 -0800

> side of their value, not that it's negotiated.

This is especially important.  "negotiation" here makes zero sense.

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 23 Nov 2013 16:19:16 +0100

> a=sctpmap:5000 webrtc-datachannel [streams] [max-message-size]
... and what is the semantic if max-message-size is not provided? The endpoint
is willing to accept arbitrary large messages?

Best regards
Michael
> 
> /Salvatore
> 
> 
> On Nov 23, 2013, at 1:35 AM, Peter Thatcher <[email-masked]>
>  wrote:
> 
>> 
>> 
>> 
>> On Fri, Nov 22, 2013 at 3:31 PM, Michael Tuexen <[email-masked]> wrote:
>> On Nov 23, 2013, at 12:16 AM, Peter Thatcher <[email-masked]> wrote:
>> 
>> > On Fri, Nov 22, 2013 at 2:51 PM, Justin Uberti <[email-masked]> wrote:
>> > On Fri, Nov 22, 2013 at 2:28 PM, Peter Thatcher <[email-masked]> wrote:

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 23 Nov 2013 23:53:00 +0100

On Nov 23, 2013, at 10:32 PM, Eric Rescorla <[email-masked]> wrote:

> 
> 
> 
> On Sat, Nov 23, 2013 at 7:19 AM, Michael Tuexen <[email-masked]> wrote:
The semantic Peter suggested was:
You can handle messages up to the limit provided in the SDP. What happens
with larger messages is unspecified.
For this semantic I suggest the name supported-message-size.

If, which is not suggested by Peter as far as I understand, the semantic is
You can handle messages up to the limit provided in the SDP. If you send
a larger message, I can't handle it.
For this semantic max-message-size would be appropriate.

No matter which semantic you choose, as a peer I would not send a message
larger than the limit since in the first case I don't know if it can be
handled, in the second case I'm sure.
> side of their value, not that it's negotiated.
Sure.

Best regards
Michael

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 24 Nov 2013 08:15:30 -0800

For concreteness, here's what I suggest.

- An SDP attribute which indicates the maximum message size that
  the endpoint is willing to accept. The other side should assume that
  any larger message will be rejected, though there is no requirement
  that it do so (just as there is no requirement to behave in any
  particular way if an unadvertised RTP PT is received).

- If the attribute is not present, the assumption is that there is some
  sensible (small) default that matches the behavior of existing
  browsers. 64k?

- An attribute value of '0' means I will do my best with whatever you
  send me, subject to memory capacity, etc.

- Proposed name: 'max-message-size'

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 24 Nov 2013 08:41:11 -0800

And in case it's not obvious, there probably also needs to be a way to
interrogate the PC to find the current remote value so that the
application can chunk if it wants.

-Ekr

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 24 Nov 2013 17:47:03 +0100

> - Proposed name: 'max-message-size'
I agree with the semantic, but I think 'supported-message-size' describes
better what you describe above. It is not the maximum, since it is not specified
what happens with larger messages. Don't get me wrong: I like you semantic,
just find the name a bit misleading.

Why not remove your second point? If the sender wants to limit the size,
it will signal it in SDP, if it has no limit, it doesn't signal it.

Best regards
Michael
> 
> -Ekr
> 
> 
> 
> On Sat, Nov 23, 2013 at 2:54 PM, Martin Thomson <[email-masked]> wrote:

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 24 Nov 2013 08:51:35 -0800

> just find the name a bit misleading.

I would be fine with your proposed name.

> it will signal it in SDP, if it has no limit, it doesn't signal it.

Ordinarily I would agree with you, but there are extant implementations
which don't signal so I'm thinking of minimizing failures with them.

-Ekr

Best regards

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 24 Nov 2013 22:48:44 +0100

On Nov 24, 2013, at 5:51 PM, Eric Rescorla <[email-masked]> wrote:

> 
> 
> 
> On Sun, Nov 24, 2013 at 8:47 AM, Michael Tuexen <[email-masked]> wrote:
OK.
> which don't signal so I'm thinking of minimizing failures with them.
Obviously, currently no implementation currently uses this. I just want
future implementation to provide a limit and to implement application
level reassembly for valid message size and protection against too large messages.

Maybe we can use appropriate wording to try to enforce that. Than I'm happy.

Best regards
Michael

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 25 Nov 2013 08:13:14 -0800

Your proposal all sounds good to me.  I don't feel strongly one way or the
other about "max-" vs. "supported-".

---

From: Justin Uberti <[email-masked]>
Date: Mon, 25 Nov 2013 16:12:47 -0800

I agree with Eric's suggestions, including '0' as a special case.

Regarding naming, I kind of prefer "max-", as there is ample precedent for
this, e.g. maxptime, maxplaybackrate in
http://tools.ietf.org/html/draft-spittka-payload-rtp-opus-03. In fact, for
optimal consistency I would argue for |maxmsgsize|.

Regarding how the parameter is specified, I beg you not to use positional
arguments, and use fmtp named arguments instead, e.g.
a=sctpmap:5000 webrtc-datachannel
a=fmtp:5000 maxmsgsize=65536

On Mon, Nov 25, 2013 at 8:13 AM, Peter Thatcher <[email-masked]>wrote:

>> On Sat, Nov 23, 2013 at 2:54 PM, Martin Thomson <[email-masked]
>> > wrote:
>>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 25 Nov 2013 16:15:47 -0800

> a=fmtp:5000 maxmsgsize=65536

I like it.

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 27 Nov 2013 12:40:22 +0000

my reading of RFC4566 is that a=fmtp is defined only for specifying format parameter for a=rtpmap:

if we want to use the same a=fmtp for the a=sctpmap it is necessary to update the draft-ietf-mmusic-sctp-sdp-05
to specify this usage.

/Sal

On Nov 26, 2013, at 7:02 PM, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:

RFC 4566 doesn't seem to prohibit it, but there could be other precedent that I am missing.

  a=fmtp:<format> <format specific parameters>

         This attribute allows parameters that are specific to a
         particular format to be conveyed in a way that SDP does not
         have to understand them.  The format must be one of the formats
         specified for the media.  Format-specific parameters may be any
         set of parameters required to be conveyed by SDP and given

         unchanged to the media tool that will use this format.  At most
         one instance of this attribute is allowed for each format.

         It is a media-level attribute, and it is not dependent on
         charset.

On Tue, Nov 26, 2013 at 1:03 AM, Harald Alvestrand <[email-masked]<mailto:[email-masked]>> wrote:
On 11/26/2013 01:12 AM, Justin Uberti wrote:
I agree with Eric's suggestions, including '0' as a special case.

Regarding naming, I kind of prefer "max-", as there is ample precedent for this, e.g. maxptime, maxplaybackrate in http://tools.ietf.org/html/draft-spittka-payload-rtp-opus-03. In fact, for optimal consistency I would argue for |maxmsgsize|.

Regarding how the parameter is specified, I beg you not to use positional arguments, and use fmtp named arguments instead, e.g.
a=sctpmap:5000 webrtc-datachannel
a=fmtp:5000 maxmsgsize=65536

Does a=fmtp bind to arbitrary identifiers? I thought it only bound to payload types...

On Mon, Nov 25, 2013 at 8:13 AM, Peter Thatcher <[email-masked]<mailto:[email-masked]>> wrote:
Your proposal all sounds good to me.  I don't feel strongly one way or the other about "max-" vs. "supported-".

On Sun, Nov 24, 2013 at 8:15 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
For concreteness, here's what I suggest.

-Ekr

On Sat, Nov 23, 2013 at 2:54 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Nov 2013 13:12:56 +0000

Hi,

>my reading of RFC4566 is that a=fmtp is defined only for specifying format parameter for a=rtpmap: 

That is my understanding also.

Regards,

Christer

On Nov 26, 2013, at 7:02 PM, Justin Uberti <[email-masked]> wrote:

On Tue, Nov 26, 2013 at 1:03 AM, Harald Alvestrand <[email-masked]> wrote:

On Mon, Nov 25, 2013 at 8:13 AM, Peter Thatcher <[email-masked]> wrote:
Your proposal all sounds good to me.  I don't feel strongly one way or the other about "max-" vs. "supported-".

-Ekr