Subject: [avtext] draft-ietf-avtext-sdes-hdr-ext-01: One to Two byte header switching

From: Magnus Westerlund <[email-masked]>
Date: Fri, 3 Jul 2015 14:16:10 +0200

WG,

During a review of the SDES header extension document I have encountered 
an issue that depends on the interpretation of RFC5285.

So RFC 5285 states:

    There are two variants of the extension: one-byte and two-byte
    headers.  Since it is expected that (a) the number of extensions in
    any given RTP session is small and (b) the extensions themselves are
    small, the one-byte header form is preferred and MUST be supported by
    all receivers.  A stream MUST contain only one-byte or two-byte
    headers: they MUST NOT be mixed within a stream.  Transmitters SHOULD
    NOT use the two-byte form when all extensions are small enough for
    the one-byte header form.

The issue is that the SDES header extensions need to use one or two byte 
headers depends on the length of the field value of the SDES item being 
included. Especially in centralized multiparty conferences the middlebox 
lacks knowledge about what future joining participants may use as field 
values. Please remember that if any single header extension needs two 
byte headers, then all will use them.

This leads to the question if an session participant is allowed to start 
out using one byte header extensions and then at a future point if needs 
arise to carry a field value longer than 16 bytes, then it can switch to 
use the two bytes headers from here on. To me it is unclear if that is 
allowed. Switching I wouldn't call mixing, but it is not clear that you 
can perform at least one switch.

Please provide your interpretation.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 3 Jul 2015 15:36:57 +0200

Hi,

Answering my own email.

I did a bit of blunder in my thoughts when writing up. The question is 
still valid, but of lesser importance. As the setting of using one or 
two bytes header is on per SSRC basis, one needs to decide when sending 
the first header extension if one needs one or two byte headers. What 
SDES values that may be included in the SDES header extension should be 
known by then. The only possible exception is in RTP middleboxes. Thus, 
I have written the following draft text to be included in Section 4.2.1:

RTP middleboxes needs to take care to select the right type between one 
byte headers to two-byte headers when creating the first packets for an 
outgoing stream (SSRC) with header extensions. First of all it needs to 
consider all the header extensions that may potentially be used. 
Secondly, it needs to know how big the SDES items that are going to be 
included are, and if any are bigger than 16 bytes use two bytes headers. 
An RTP middlebox that forwards a stream, i.e. not mixing it or combing 
it with others, may be able to base its choice on incoming streams 
choice of headers. This is assuming that the middlebox do not modify the 
stream and add additional header extensions to the stream it sends, in 
which case it needs to make its own determination.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 3 Jul 2015 17:08:31 +0000

Hi Magnus,

I agree with your interpretation of RFC 5285, since it mentions this restriction for a "stream" which is presumably an SSRC. However, I see no motivation for the restriction. So perhaps this should be updated.

In fact, I think there may be incorrect normative language around 1 vs 2 byte headers. It says receivers MUST support 1 byte headers and senders SHOULD use them when sufficient. No normative language for 2 byte headers, coupled with the fact that the ID space 1-14 is shared by 1 and 2 byte headers, leads to some serious issues that make 2 byte headers useless in some cases. A sender could negotiate ID=1-14, send 2 byte headers, and never be aware the receiver does not support them. I consider this a serious design flaw. A potential solution is to require ID>15 for 2 byte headers so they can be successfully negotiated. Such an update could also relax the restriction of using only 1 or 2 byte headers within a single stream/SSRC so it only applies within a single packet. 

Thanks,
Mo

On Jul 3, 2015, at 9:37 AM, Magnus Westerlund <[email-masked]> wrote:

Hi,

Answering my own email.

I did a bit of blunder in my thoughts when writing up. The question is still valid, but of lesser importance. As the setting of using one or two bytes header is on per SSRC basis, one needs to decide when sending the first header extension if one needs one or two byte headers. What SDES values that may be included in the SDES header extension should be known by then. The only possible exception is in RTP middleboxes. Thus, I have written the following draft text to be included in Section 4.2.1:

RTP middleboxes needs to take care to select the right type between one byte headers to two-byte headers when creating the first packets for an outgoing stream (SSRC) with header extensions. First of all it needs to consider all the header extensions that may potentially be used. Secondly, it needs to know how big the SDES items that are going to be included are, and if any are bigger than 16 bytes use two bytes headers. An RTP middlebox that forwards a stream, i.e. not mixing it or combing it with others, may be able to base its choice on incoming streams choice of headers. This is assuming that the middlebox do not modify the stream and add additional header extensions to the stream it sends, in which case it needs to make its own determination.

Cheers

Magnus

-- 

Magnus Westerlund

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

---

From: Magnus Westerlund <[email-masked]>
Date: Sun, 5 Jul 2015 22:41:51 +0200

Mo Zanaty (mzanaty) skrev den 2015-07-03 19:08:
> Hi Magnus,
>
> I agree with your interpretation of RFC 5285, since it mentions this
> restriction for a "stream" which is presumably an SSRC. However, I
> see no motivation for the restriction. So perhaps this should be
> updated.

I also wonder over the motivation for this restriction. I can't remember 
why this was the result. I do have to note that RFC 5285 is obviously 
written with the assumption that one m= line means one RTP stream.

>
> In fact, I think there may be incorrect normative language around 1
> vs 2 byte headers. It says receivers MUST support 1 byte headers and
> senders SHOULD use them when sufficient. No normative language for 2
> byte headers, coupled with the fact that the ID space 1-14 is shared
> by 1 and 2 byte headers, leads to some serious issues that make 2
> byte headers useless in some cases. A sender could negotiate ID=1-14,
> send 2 byte headers, and never be aware the receiver does not support
> them. I consider this a serious design flaw. A potential solution is
> to require ID>15 for 2 byte headers so they can be successfully
> negotiated. Such an update could also relax the restriction of using
> only 1 or 2 byte headers within a single stream/SSRC so it only
> applies within a single packet.

I think the easiest fix will be to mandate support of both formats, 
period. There is quite a small implementation burden of supporting both 
formats, while signalling implementation will easily be more complex. I 
also note that there is another limitation in the RFC that one would 
have to violate to do your suggested fix.

    An extension URI with the same attributes MUST NOT appear more than
    once applying to the same stream, i.e., at session level or in the
    declarations for a single stream at media level.

This, has some potential for backwards compatibility issues, so I would 
prefer to not change it.

However, improving RFC 5285 is an AVTCORE issue. As soon as we are 
agreeing on the problems, we should move the discussion to that list.

Cheers

Magnus

> Thanks, Mo
> I did a bit of blunder in my thoughts when writing up. The question
> is still valid, but of lesser importance. As the setting of using one
> or two bytes header is on per SSRC basis, one needs to decide when
> sending the first header extension if one needs one or two byte
> headers. What SDES values that may be included in the SDES header
> extension should be known by then. The only possible exception is in
> RTP middleboxes. Thus, I have written the following draft text to be
> included in Section 4.2.1:
>
> RTP middleboxes needs to take care to select the right type between
> one byte headers to two-byte headers when creating the first packets
> for an outgoing stream (SSRC) with header extensions. First of all it
> needs to consider all the header extensions that may potentially be
> used. Secondly, it needs to know how big the SDES items that are
> going to be included are, and if any are bigger than 16 bytes use two
> bytes headers. An RTP middlebox that forwards a stream, i.e. not
> mixing it or combing it with others, may be able to base its choice
> on incoming streams choice of headers. This is assuming that the
> middlebox do not modify the stream and add additional header
> extensions to the stream it sends, in which case it needs to make its
> own determination.
>
> Cheers
>
> Magnus
>
>> During a review of the SDES header extension document I have
>> encountered an issue that depends on the interpretation of
>> RFC5285.
>>
>> So RFC 5285 states:
>>
>> headers.  Since it is expected that (a) the number of extensions
>> in any given RTP session is small and (b) the extensions themselves
>> are small, the one-byte header form is preferred and MUST be
>> supported by all receivers.  A stream MUST contain only one-byte or
>> two-byte headers: they MUST NOT be mixed within a stream.
>> Transmitters SHOULD NOT use the two-byte form when all extensions
>> are small enough for the one-byte header form.
>>
>> The issue is that the SDES header extensions need to use one or two
>> byte headers depends on the length of the field value of the SDES
>> item being included. Especially in centralized multiparty
>> conferences the middlebox lacks knowledge about what future joining
>> participants may use as field values. Please remember that if any
>> single header extension needs two byte headers, then all will use
>> them.
>>
>> This leads to the question if an session participant is allowed to
>> start out using one byte header extensions and then at a future
>> point if needs arise to carry a field value longer than 16 bytes,
>> then it can switch to use the two bytes headers from here on. To me
>> it is unclear if that is allowed. Switching I wouldn't call mixing,
>> but it is not clear that you can perform at least one switch.
>>
>> Färögatan 6                 | Mobile +46 73 0949079 SE-164 80
>> Stockholm, Sweden | mailto: [email-masked]

-- 

Magnus Westerlund

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Tue, 7 Jul 2015 02:16:39 +0000

Hi Magnus,

I agree any new spec (whether a specific extension or a general extension
mechanism) should simply mandate support of both formats. However,
interworking with existing implementations will still be a problem. The
issue is that negotiating extension ID=1-14 in SDP will always leave
senders with uncertainty if the receiver supports 2-byte extensions,
unless there is some other signaling which provides that certainty. If a
sender knows 2-byte extensions are necessary (because 1-byte is
insufficient), it should probably try to negotiate ID>15 for those
extensions. I did not mean to imply offering both 1-byte (1-14) and 2-byte
(>15) versions of the same extension in signaling, which RFC 5285 clearly
prohibits.

Cheers,
Mo

On 7/5/15, 4:41 PM, Magnus Westerlund <[email-masked]>
wrote:
<snip>

Cheers

Magnus