Subject: Re: [AVTCORE] [avtcore] WGLC for mux-category issue of draft-ietf-avtcore-rfc5285-bis-12

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Mon, 3 Jul 2017 00:50:17 +0000

Hi Folks,

Sorry about the typo. It should be draft-ietf-avtcore-rfc5285-bis-12.

BR,
Rachel

From: avt [mailto:[email-masked]] On Behalf Of Huangyihong (Rachel)
Sent: Thursday, June 29, 2017 2:05 PM
To: [email-masked]
Subject: [AVTCORE] [avtcore] WGLC for mux-category issue of draft-ietf-avtcore-rfc5282-bis-12

Hi Folks,

As you may notice that there was a discussion for the mux category selection for a=extmap-allow-mixed in draft-ietf-avtcore-rfc5282-bis-12. This issue was raised by Magnus when he was doing the shepherd work. See https://mailarchive.ietf.org/arch/msg/avt/BaElJmDlmDtOaAcXKV_Rk5fARgk. This discussion happened after the WGLC and no formal conclusion was made then.

And now the discussion is restarted in IESG review of this draft. The author thinks it should be Normal to cover multiple cases, while some people think it's better to be Identical to make things simple.

So this email is to have a one-week WGLC for this issue and deliver a formal conclusion to IESG:

If you do not agree that "Normal" mux category should be used for a=extmap-allow-mixed, please express it in the mailing list before 8th July.

Thanks.

BR,
Rachel (as the co-chair)

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 4 Jul 2017 15:38:54 +0200

Hi,

As one of the people who raised this before I want to explain why I 
think it should identical makes more sense in this case.

So first the assumptions. We are talking about offers in the context of 
BUNDLE, i.e. multiple m= blocks are part of the same RTP session. Thus, 
these RTP streams generated will be received and sent by a particular 
endpoint on the same transport port. Thus, the RTP stack processing will 
be done by a single implementation.

The single RTP stack implementation in a BUNDLE context is the basis for 
my argument why it makes sense to use identical for extmap-allow-mixed. 
The reason is that the entity on the specified IP address + port will be 
a single implementation. Thus, I assume it is capable of handling the 
switching between one and two-byte extension header formats without 
issues. From this perspective identical appears very reasonable.

The argument that David Singer brought to the table is that one may have 
different capabilities for audio and video in an endpoint. So from my 
perspective, this can only really work if the RTP payload content is 
forwarded from the media producing entity and processed by the RTP stack 
in such a way that they fulfill the RTP protocol specification. If 
necessary, then rewriting could happen in that forwarding. But, that 
should really not be needed. First the signaling that enable RTP header 
extension usage can control its side of the negotiation and what IDs are 
used. Remember that the ID space becomes joint over all extensions in 
the RTP session, but different RTP streams and media blocks may have 
only a subset of all header extensions configured. Thus, if audio stream 
generator have this limitation that it only can process one-byte header 
extensions, only IDs that fits the short can be assigned, if at all 
possible. Thus, the only threat would be a sender that uses two-byte 
headers when it is not needed.

So the benefits as I see with identical is the following. For an BUNDLE 
capable implementation where the implementation that adds header 
extensions to the RTP packets is common, there is consistent 
configuration for the RTP session, and the possibility to switch at any 
point reduces the complexity of the code-base as no attempt to predict 
or determine future needs are needed. Use what is currently needed. No 
extra complexity for this modern implementations to deal with legacy 
implementations into bundle scenario.

That complexity of ensuring which IDs are used, and dealing with 
adopting a legacy implementation to BUNDLE ends up with the ones doing 
that choice, not everyone else. And this is for a case I at least see as 
strange as all RTP streams will flow over the same 5-tuple for the 
different media types. Thus, only implementation that attempts to 
forward RTP packets without rewriting will have this issue.

If one allows Normal, then one pushes the complexities of having to be 
able to restrict some RTP streams in an RTP session to not switch 
between one and two-byte headers. This will require code, and also more 
signaling logic to deal with cases where this is offered. Thus, I think 
using identical would simplify the system in general. And allow modern 
BUNDLE capable implementations to becomes simpler, for a little cost for 
the implementers that attempt to integrate legacy packet generators into 
a single RTP session without a translation layer, or back to back RTP 
sessions.

Cheers

Magnus

Den 2017-06-29 kl. 08:05, skrev Huangyihong (Rachel):
>
> Hi Folks,
>
> As you may notice that there was a discussion for the mux category 
> selection for a=extmap-allow-mixed in 
> draft-ietf-avtcore-rfc5282-bis-12. This issue was raised by Magnus 
> when he was doing the shepherd work. See 
> https://mailarchive.ietf.org/arch/msg/avt/BaElJmDlmDtOaAcXKV_Rk5fARgk. 
> This discussion happened after the WGLC and no formal conclusion was 
> made then.
>
> And now the discussion is restarted in IESG review of this draft. The 
> author thinks it should be Normal to cover multiple cases, while some 
> people think it’s better to be Identical to make things simple.
>
> If you do not agree that “Normal” mux category should be used for 
> a=extmap-allow-mixed, please express it in the mailing list before 
> 8^th July.
>
> Thanks.
>
> BR,
>
> Rachel (as the co-chair)
>

-- 

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Roni Even <[email-masked]>
Date: Wed, 12 Jul 2017 05:53:43 +0000

Hi,
My reason for suggesting Normal is that it provides more flexibility for implementations. I understand Magnus point about the added complexity of supporting a mixed mode where some m-lines allow-mix while other not. Yet since this is a negotiated attribute than it leaves it to the implementations if they want to offer allow mix in all m-lines or at the session level or not. I am not sure why we should limit ourselves to mandating identical since as Dave Singer pointed out there may be cases where we want the normal case.  If we define it as identical it means that allow-mix MUST be supported which is not what the draft says for this attribute in the  general case. I also think that there is always the option to use only two-bytes RTP header extensions when in doubt as the draft says.
Roni

From: avt [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: יום ג 04 יולי 2017 16:39
To: Huangyihong (Rachel); [email-masked]
Subject: Re: [AVTCORE] [avtcore] WGLC for mux-category issue of draft-ietf-avtcore-rfc5282-bis-12

Hi,

As one of the people who raised this before I want to explain why I think it should identical makes more sense in this case.

So first the assumptions. We are talking about offers in the context of BUNDLE, i.e. multiple m= blocks are part of the same RTP session. Thus, these RTP streams generated will be received and sent by a particular endpoint on the same transport port. Thus, the RTP stack processing will be done by a single implementation.

The single RTP stack implementation in a BUNDLE context is the basis for my argument why it makes sense to use identical for extmap-allow-mixed. The reason is that the entity on the specified IP address + port will be a single implementation. Thus, I assume it is capable of handling the switching between one and two-byte extension header formats without issues. From this perspective identical appears very reasonable.

The argument that David Singer brought to the table is that one may have different capabilities for audio and video in an endpoint. So from my perspective, this can only really work if the RTP payload content is forwarded from the media producing entity and processed by the RTP stack in such a way that they fulfill the RTP protocol specification. If necessary, then rewriting could happen in that forwarding. But, that should really not be needed. First the signaling that enable RTP header extension usage can control its side of the negotiation and what IDs are used. Remember that the ID space becomes joint over all extensions in the RTP session, but different RTP streams and media blocks may have only a subset of all header extensions configured. Thus, if audio stream generator have this limitation that it only can process one-byte header extensions, only IDs that fits the short can be assigned, if at all possible. Thus, the only threat would be a sender that uses two-byte headers when it is not needed.

So the benefits as I see with identical is the following. For an BUNDLE capable implementation where the implementation that adds header extensions to the RTP packets is common, there is consistent configuration for the RTP session, and the possibility to switch at any point reduces the complexity of the code-base as no attempt to predict or determine future needs are needed. Use what is currently needed. No extra complexity for this modern implementations to deal with legacy implementations into bundle scenario.

That complexity of ensuring which IDs are used, and dealing with adopting a legacy implementation to BUNDLE ends up with the ones doing that choice, not everyone else. And this is for a case I at least see as strange as all RTP streams will flow over the same 5-tuple for the different media types. Thus, only implementation that attempts to forward RTP packets without rewriting will have this issue.

If one allows Normal, then one pushes the complexities of having to be able to restrict some RTP streams in an RTP session to not switch between one and two-byte headers. This will require code, and also more signaling logic to deal with cases where this is offered. Thus, I think using identical would simplify the system in general. And allow modern BUNDLE capable implementations to becomes simpler, for a little cost for the implementers that attempt to integrate legacy packet generators into a single RTP session without a translation layer, or back to back RTP sessions.

Cheers

Magnus

And now the discussion is restarted in IESG review of this draft. The author thinks it should be Normal to cover multiple cases, while some people think it’s better to be Identical to make things simple.

If you do not agree that “Normal” mux category should be used for a=extmap-allow-mixed, please express it in the mailing list before 8th July.

Thanks.

BR,
Rachel (as the co-chair)

--

Magnus Westerlund

SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 12 Jul 2017 08:28:50 +0200

Hi Roni,

Den 2017-07-12 kl. 07:54, skrev Roni Even:
>
> Hi,
>
> My reason for suggesting Normal is that it provides more flexibility 
> for implementations. I understand Magnus point about the added 
> complexity of supporting a mixed mode where some m-lines allow-mix 
> while other not. Yet since this is a negotiated attribute than it 
> leaves it to the implementations if they want to offer allow mix in 
> all m-lines or at the session level or not. I am not sure why we 
> should limit ourselves to mandating identical since as Dave Singer 
> pointed out there may be cases where we want the normal case.
>

And my point in relation to Dave Singer's use case is that the endpoint 
wanting to have one media type being produced according to not 
supporting mixed, and having the rest of the session allow mixed still 
have to have a RTP receiver front-end capable of dealing with that, and 
a signaling implementation. Thus, that endpoint can take the cost for 
handling that use case, rather than putting it on everyone else to deal 
with that case.

> If we define it as identical it means that allow-mix MUST be supported 
> which is not what the draft says for this attribute in the  general 
> case. I also think that there is always the option to use only 
> two-bytes RTP header extensions when in doubt as the draft says.
>

I need to comment on the last part. I don't think it requires it to be 
supported. Identical only requires one to have the same value for all m= 
lines part of the same RTP session, i.e. all RTP m= lines in the same 
bundle group. Thus, not having a=extmap-allow-mixed on any m= line in 
the bundle group is a valid use.

Cheers

Magnus

> Roni
>
> *From:*avt [mailto:[email-masked]] *On Behalf Of *Magnus Westerlund
> *Sent:* יום ג 04 יולי 2017 16:39
> *To:* Huangyihong (Rachel); [email-masked]
> *Subject:* Re: [AVTCORE] [avtcore] WGLC for mux-category issue of 
> draft-ietf-avtcore-rfc5282-bis-12
>
> Hi,
>
> So first the assumptions. We are talking about offers in the context 
> of BUNDLE, i.e. multiple m= blocks are part of the same RTP session. 
> Thus, these RTP streams generated will be received and sent by a 
> particular endpoint on the same transport port. Thus, the RTP stack 
> processing will be done by a single implementation.
>
> The single RTP stack implementation in a BUNDLE context is the basis 
> for my argument why it makes sense to use identical for 
> extmap-allow-mixed. The reason is that the entity on the specified IP 
> address + port will be a single implementation. Thus, I assume it is 
> capable of handling the switching between one and two-byte extension 
> header formats without issues. From this perspective identical appears 
> very reasonable.
>
> The argument that David Singer brought to the table is that one may 
> have different capabilities for audio and video in an endpoint. So 
> from my perspective, this can only really work if the RTP payload 
> content is forwarded from the media producing entity and processed by 
> the RTP stack in such a way that they fulfill the RTP protocol 
> specification. If necessary, then rewriting could happen in that 
> forwarding. But, that should really not be needed. First the signaling 
> that enable RTP header extension usage can control its side of the 
> negotiation and what IDs are used. Remember that the ID space becomes 
> joint over all extensions in the RTP session, but different RTP 
> streams and media blocks may have only a subset of all header 
> extensions configured. Thus, if audio stream generator have this 
> limitation that it only can process one-byte header extensions, only 
> IDs that fits the short can be assigned, if at all possible. Thus, the 
> only threat would be a sender that uses two-byte headers when it is 
> not needed.
>
> So the benefits as I see with identical is the following. For an 
> BUNDLE capable implementation where the implementation that adds 
> header extensions to the RTP packets is common, there is consistent 
> configuration for the RTP session, and the possibility to switch at 
> any point reduces the complexity of the code-base as no attempt to 
> predict or determine future needs are needed. Use what is currently 
> needed. No extra complexity for this modern implementations to deal 
> with legacy implementations into bundle scenario.
>
> that choice, not everyone else. And this is for a case I at least see 
> as strange as all RTP streams will flow over the same 5-tuple for the 
> between one and two-byte headers. This will require code, and also 
> more signaling logic to deal with cases where this is offered. Thus, I 
> think using identical would simplify the system in general. And allow 
> modern BUNDLE capable implementations to becomes simpler, for a little 
> cost for the implementers that attempt to integrate legacy packet 
> generators into a single RTP session without a translation layer, or 
> back to back RTP sessions.
>
> Cheers
>
> Magnus
>
>     This discussion happened after the WGLC and no formal conclusion
>     was made then.
>
>     And now the discussion is restarted in IESG review of this draft.
>     The author thinks it should be Normal to cover multiple cases,
>     while some people think it’s better to be Identical to make things
>     simple.
>
> SE-164 80 Stockholm, Sweden | mailto:[email-masked] <mailto:[email-masked]>

-- 

Magnus Westerlund