Re: [MMUSIC] BUNDLE - MID Security - Updated text proposal

[Magnus Westerlund <[e-mail]>]

Den 2016-11-03 kl. 17:36, skrev Ted Hardie:
> On Thu, Nov 3, 2016 at 6:52 AM, Magnus Westerlund
> <[e-mail] <mailto:[e-mail]>>
> wrote:
>
>     Den 2016-11-02 kl. 21:07, skrev Adam Roach:
>
>         On 11/2/16 14:11, Cullen Jennings wrote:
>
>             I'd also like to give any reasonable advice we can on
>             creating MIDs
>             such that they meet that goal.  Is there any reason not to
>             just make
>             MID a 16 bit integer ? same for RID ?
>
>
>
>         draft-ietf-avtext-rid is in the RFC editors' queue. We *might*
>         be able
>         to pull off minor editorial changes. As far as I understand things,
>         changing the format of a field would require us to pull it back
>         and put
>         it through IETF LC and IESG review again.
>
>         In terms of the actual proposed change ("16 bit integer"), SDES is
>         defined to be a UTF-8 string. Unless we want to define a whole other
>         thing instead of using SDES, these identifiers have to be valid
>         UTF-8.
>
>
>     I agree with Adam here that going to something that isn't UTF-8
>     makes it more difficult. It will not match the standard SDES format.
>     I think it is desirable that we can have a single character and
>     single byte in most cases, while still allowing for multiple ones in
>     cases where there are many MIDs or RIDs. But basically if one uses
>     0-9, a-z, A-Z, and then goes to 00, 01, .. 0a, etc, then one can
>     with two characters 62^2 = 3844 possible ids, and the scheme should
>     not be restricted to just two if actually needed. The SDES has an
>     upper limit of 255 bytes.
>
>
> Okay, so I was going to suggest we leave RID alone and have an optional
> suggestion that MID be a 16 bit integer, represented as an
> SDES-compatible UTF-8 string (that should be 5 octets maximum).  Someone
> interested in code re-use could always use that with RID as well, even
> though the RID document doesn't have the same suggestion.  While this
> would be optional advice, you're concerned that someone taking it would
> consume 10 of the  255 available octets?
>

As RTP header extensions are added in some potentially quite a lot of 
RTP packets and they take away from the available codec payload MTU, we 
consume quite a lot of space. For allowing rapid start performance for 
an RTP stream that hasn't been sent before, and the signalling answer 
hasn't made it yet, one need to include CNAME, MID, and RID in the RTP 
header extension. Assuming the MID and RID SDES items are 5 bytes each, 
that would drive the full RTP header extension to become:

4 bytes Header Extension common header
1 byte HE Item header
16 bytes CNAME data
1 byte HE item header
5 bytes MID data
1 byte HE item header
5 bytes RID data
3 bytes padding (for 32 bit-word alignment)
Total: 36 bytes

Compare this with 1 byte MID and RID:

4 bytes Header Extension common header
1 byte HE Item header
16 bytes CNAME data
1 byte HE item header
1 bytes MID data
1 byte HE item header
1 bytes RID data
3 bytes padding (for 32 bit-word alignment)

Total: 28 bytes

So in this case it ended up being just the 8 extra bytes the format.
Also without the CNAME, it is just 8 bytes difference, but then the 
total sizes are 16 vs 8 bytes.

Looking at this from where it does matter. As soon as one have more than 
9 media descriptions (m=) then one adds 4 bytes to the size of the 
Header Extension when using an integer scheme. Using a enumeration with 
like 0-9, a-z and A-Z then that break point happens after 62 media 
descriptions. Looking at today's cases, the first is likely, the second 
much less so.

I also don't quite see that enumerating using digits and a-z is 
particular difficult. It may require some few more sentence in the 
description, but not particular lot of code. Writing a m= line index to 
mid ID converter is very small function. And it is just the generation 
side that needs to care. After that they are just opaque identifiers.

And this would save both bytes on the wire and MTU.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------