Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-negotiation-32 (Part I)

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Oct 2016 17:30:18 -0700

On Mon, Aug 29, 2016 at 12:54 PM, Christer Holmberg <
[email-masked]> wrote:

> Hi Ekr,
>
>
>
> Thanks for the comments! Please see inline.
>
>
>
> OVERALL
>
>
>
> >The overall framing of this document as being about attaching multiple
>
> >m= sections to a single "shared address" is extremely problematic,
>
> >for two reasons:
>
> >
>
> >- With ICE there isn't actually any notion of a shared address except
>
> >  in some vague sense. I suppose you could argue that because with
>
> >  ICE you are required to specify a port on the m= line then you
>
> >  still have a concept of an address, but that's not true in
>
> >  trickle ICE, where the port is 9, so all m= lines share the same
>
> >  address/port. So, actually when you use trickle a whole bunch of
>
> >  the statements in this document are wrong.
>
> >
>
> >- A lot more is being overloaded here than addresses. In fact, a whole
>
> >  pile of semantics are being overloaded, so the way to think about
>
> >  this is actually as gluing a whole bunch of m= lines together at
>
> >  the transport level.
>
> >
>
> > I think the right concept here is not "shared address" but "bundle group"
>
> > and the document should be written in that way, namely that there are
>
> > a  bunch of m= lines in a bundle group and the one with the bundle tag
>
> > is the one that sets all the shared parameters.
>
>
>
> It is true that the actual port value in the m- line, and the IP address
> in the c- line address, represent the address that is actually being used.
>
>
>
> But, even with ICE there is a shared address, isn’t there? Yes, that
> shared address may change, but at any given time there will be one address
> that is shared among the media streams within the BUNDLE group. Or?
>

Not if you trickle, no. Then all the m= lines have the same address whether
they are bundled or not.

MAJOR TECHNICAL
>
>
>
> > Maybe I missed this, but I don't see any requirement that m= lines
>
> > appear in the a=group:BUNDLE line in the order they appear in the
>
> > SDP. That would make life a lot easier.
>
>
>
> There is no such requirement.
>
>
>
> AFAIR, it was discussed at some point, but it was agreed to not mandate m-
> lines to be listed in the order of preference (as far as selecting the
> BUNDLE address is concerned).
>
>
>
> Also, if you mid-session adds a new m- line, and wants that to represent
> the new BUNDLE address you have to place the new m- line after the existing
> m- lines, but you have to place it first in the a=group:BUNDLE attribute
> list.
>

OK. Well, that would be useful to state clearly upfront.

DETAILED COMMENTS (MIXED EDITORIAL/TECHNICAL)
>
>
>
> >S 1.
>
> >This really needs some explanation of why you would want this feature.
>
>
>
> You represent the community that wants the feature, so feel free to
> suggest some text explaining why you want it :)
>

"Each 5-tuple for which communications are set up consumes additional
resources (especially when ICE is in use). For this reason, it is
attractive to have as many different flows as possible multiplexed over the
same 5-tuple."

>S 5.
>
> >The first three grafs of this section seem to duplicate the intro
>
> >and the abstract.
>
> >
>
> >Also, this claim about sharing a 5-tuple is not quite right with ICE
>
> >because ICE can switch 5-tuples during aggressive nomination.
>
>
>
> Yes. But, at any given time there will only be one 5-tuple, won’t it?
>

Not really no, no, because it's asymmetrical.

Say that we have two candidate pairs A and B with B higher priority than A.
The controlling endpoint sends checks on A and B but the initial check for
A is dropped
whereas the one for B is not. This establishes a flow on B at which point
both controlling
and controlled endpoints are sending on B. Then the controlling endpoint
retransmits the
check for A. At the point when the controlled endpoint receives that check
it starts transmitting
on A, but the controlling endpoint is still sending on B. So, the
controlled endpoint has to
simultaneously transmit on A but send on B.

>
>
> >S 8.1.
>
> >This seems like a key concept: there are a number of different categories
>
> >of attributes and some are shared with all members of a bundle group
>
> >and some are not. To what extent is this draft just duplicative of those
>
> >listed in the mux-attributes draft?
>
>
>
> Not sure I understand the question.
>

My point is that the concept you need to know for *this draft* is:

- Some attributes are shared and some are not.

The detailed rules are defined in the mux attributes draft, right?

> >S 8.2 and following
>
> >Really would be useful to have some examples here to make it less
>
> >abstract.
>
>
>
> You don’t think the examples in section 17 are enough? You want examples
> in the normative sections describing how to create offers, answers etc?
>

Yes. Partial examples would be fine.

>S 8.5.
>
> >How does this interact with ICE Restart?
>
>
>
> From a pure ICE Restart perspective, I don’t see any conflict. ICE Restart
> is triggered by changing the user name and password, and the text does not
> forbid that.
>
>
>
> If you also want to change the BUNDLE address, you follow the rules in
> section 8.5.1.
>

My concern is this text "   These rules imply that setting the IP address
in the c line to

   0.0.0.0 will cause an ICE restart.  Consequently, ICE implementations
   MUST NOT utilize this mechanism for call hold, and instead MUST use

   a=inactive and a=sendonly as described in [RFC3264
<https://tools.ietf.org/html/rfc3264>]."

> >S 8.5.2
>
> >When you say "extend" do you mean "add to the end"?
>
>
>
> Yes. I can fix that.
>
>
>
>
>
> >S 10.1
>
> >In this first bullet is "if" "iff"?
>
>
>
> “iff”?
>

"if and only if"

> >S 10.3.1.1.
>
> >   When an offerer generates an initial offer, the offerer MUST
>
> >   associate either an SDP 'rtcp-mux' attribute [RFC5761] or an SDP
>
> >   'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] with each
>
> >   bundled RTP-based "m=" line in the offer.  The offerer MUST associate
>
> >   an SDP 'rtcp-mux-only' attribute with each bundle-only "m=" line.  If
>
> >   the offerer associates a 'rtcp-mux-only' attribute with an "m=" line,
>
> >   the offerer may also associate a 'rtcp-mux' attribute with the same
>
> >   "m=" line, as described in [I-D.ietf-mmusic-mux-exclusive].
>
> >
>
> > This is a particularly egregious case of associate disease that could
>
> > be easily solved by using "add" when referring to the attributes
>
> > you put in the m= section.
>
>
>
> People have previously said that you don’t “add” attributes to m- lines:
> you add port values etc, but not attributes.
>
>
>
> This is an example of where I’ve had to re-write big parts of the
> documents a number of times already, because every time someone else reads
> the document he/she is not happy with the terminology. I just don’t want to
> do it again.
>

The terminology that JSEP uses is that "m= sections" include attribute
lines.

I think this is a lot clearer.

> >S 11.1
>
> >   When an offerer associates a unique address with a bundled "m=" line
>
> >   (excluding any bundle-only "m=" line), the offerer MUST associate SDP
>
> >   'candidate' attributes (and other applicable ICE-related media-level
>
> >   SDP attributes), containing unique ICE properties (candidates etc),
>
> >   with the "m=" line, according to the procedures in
>
> >   [I-D.ietf-mmusic-ice-sip-sdp].
>
> >
>
> > Here is an example of where the "address" framing doesn't work, if you
>
> > are using trickle.
>
>
>
> See top of e-mail.
>

Yeah, I continue to believe that this is wrong for the reasons above.

-Ekr

> Regards,
> Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Oct 2016 11:01:21 +0000

Hi,

OVERALL

> is the one that sets all the shared parameters.

It is true that the actual port value in the m- line, and the IP address in the c- line address, represent the address that is actually being used.

But, even with ICE there is a shared address, isn’t there? Yes, that shared address may change, but at any given time there will be one address that is shared among the media streams within the BUNDLE group. Or?

Not if you trickle, no. Then all the m= lines have the same address whether they are bundled or not.

Ok, I hear you. You are basically saying that it doesn’t matter whether bundled m- lines share addresses or not – the ONLY thing that matters is that the m- line associated with the bundle tag contains the address to be used.

The reason we mandated shared addresses, once the usage of BUNDLE had been negotiated, was because of intermediaries that don’t support BUNDLE (to make sure they send media towards the correct address). But, maybe we don’t need to worry about anymore – BUNDLE probably won’t work reliably with such intermediaries anyway…

Also, there is at least once case where the address matters: when you add a new m- line to a bundle group. If you use a unique address, and the answerer does not accept the m- line in the BUNDLE group, it can be used un-bundled. If you use a shared address, the answerer will have to reject the m- line.

MAJOR TECHNICAL

AFAIR, it was discussed at some point, but it was agreed to not mandate m- lines to be listed in the order of preference (as far as selecting the BUNDLE address is concerned).

Also, if you mid-session adds a new m- line, and wants that to represent the new BUNDLE address you have to place the new m- line after the existing m- lines, but you have to place it first in the a=group:BUNDLE attribute list.

I’ll think of some wording.

>This really needs some explanation of why you would want this feature.

You represent the community that wants the feature, so feel free to suggest some text explaining why you want it :)

"Each 5-tuple for which communications are set up consumes additional resources (especially when ICE is in use). For this reason, it is attractive to have as many different flows as possible multiplexed over the same 5-tuple."

l’ll add that.

Say that we have two candidate pairs A and B with B higher priority than A.
The controlling endpoint sends checks on A and B but the initial check for A is dropped
whereas the one for B is not. This establishes a flow on B at which point both controlling
and controlled endpoints are sending on B. Then the controlling endpoint retransmits the
check for A. At the point when the controlled endpoint receives that check it starts transmitting
on A, but the controlling endpoint is still sending on B. So, the controlled endpoint has to
simultaneously transmit on A but send on B.

Sure, different 5-tuples may be used in each direction, as indicated in the two first paragraphs.

I guess we could remove “5-tuple” text in the 3rd paragraph, and only say that all media associated with a BUNDLE group is sent using the same transport layer protocol.

Yes. So, perhaps we should not use RFC2119 terminology in draft-bundle, but simple refer to draft-mux-attributes for the rules.

>Really would be useful to have some examples here to make it less

You don’t think the examples in section 17 are enough? You want examples in the normative sections describing how to create offers, answers etc?

I’ll look into that.

>From a pure ICE Restart perspective, I don’t see any conflict. ICE Restart is triggered by changing the user name and password, and the text does not forbid that.

If you also want to change the BUNDLE address, you follow the rules in section 8.5.1.

My concern is this text "   These rules imply that setting the IP address in the c line to

   a=inactive and a=sendonly as described in [RFC3264<https://tools.ietf.org/html/rfc3264>]."

Correct. So, if you use BUNDLE and want to trigger an ICE restart, you do as described above. BUNDLE does not define usage of 0.0.0.0 in the c line, so there should be no conflict.

Or, do I still misunderstand you issue?

Yes. I can fix that.

“iff”?

"if and only if"

 It’s “iff”.

> you put in the m= section.

People have previously said that you don’t “add” attributes to m- lines: you add port values etc, but not attributes.

This is an example of where I’ve had to re-write big parts of the documents a number of times already, because every time someone else reads the document he/she is not happy with the terminology. I just don’t want to do it again.

The terminology that JSEP uses is that "m= sections" include attribute lines.

 I don’t personally disagree, but there are people that have had other opinions.

 In general I think it would be really useful to have common terminology in BUNDLE and JSEP, but I don’t want to re-write the document once again, and then later be told to do it again…

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Oct 2016 07:00:07 -0700

On Mon, Oct 3, 2016 at 4:01 AM, Christer Holmberg <
[email-masked]> wrote:

> Ok, I hear you. You are basically saying that it doesn’t matter whether
> bundled m- lines share addresses or not – the ONLY thing that matters is
> that the m- line associated with the bundle tag contains the address to be
> used.
>
> The reason we mandated shared addresses, once the usage of BUNDLE had been
> negotiated, was because of intermediaries that don’t support BUNDLE (to
> make sure they send media towards the correct address). But, maybe we don’t
> need to worry about anymore – BUNDLE probably won’t work reliably with
> such intermediaries anyway…
>
> Also, there is at least once case where the address matters: when you add
> a new m- line to a bundle group. If you use a unique address, and the
> answerer does not accept the m- line in the BUNDLE group, it can be used
> un-bundled. If you use a shared address, the answerer will have to reject
> the m- line.
>

I think this is all true, but what I am trying to say here is, I think,
conceptually different:

BUNDLED m= lines are grouped together and share a bunch of properties.
Amongst those properties is that they share IP addresses, but it's not the
only thing they share, nor is it it the indicator that they are shared
(that's the a=group:BUNDLE list). So the top-line category isn't shared
vs/unique IP address but rather bundled vs. unbundled.

> I guess we could remove “5-tuple” text in the 3rd paragraph, and only say
> that all media associated with a BUNDLE group is sent using the same
> transport layer protocol.
>

I think that would be better.

> Yes. So, perhaps we should not use RFC2119 terminology in draft-bundle,
> but simple refer to draft-mux-attributes for the rules.
>

That would be my recommendation.

>> From a pure ICE Restart perspective, I don’t see any conflict. ICE
>> Restart is triggered by changing the user name and password, and the text
>> does not forbid that.
>>
>>
>>
> Correct. So, if you use BUNDLE and want to trigger an ICE restart, you do
> as described above. BUNDLE does not define usage of 0.0.0.0 in the c line,
> so there should be no conflict.
>

OK. I'll think about it some more and let you know if I still think there's
an issue.

>> >In this first bullet is "if" "iff"?

It should say so, then, I think.

>  In general I think it would be really useful to have common terminology
> in BUNDLE and JSEP, but I don’t want to re-write the document once again,
> and then later be told to do it again…
>

Resolving the appropriate terminology seems like a chair issue.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Oct 2016 20:07:00 +0000

Hi,

OVERALL

I think this is all true, but what I am trying to say here is, I think, conceptually different:

BUNDLED m= lines are grouped together and share a bunch of properties. Amongst those properties is that they share IP addresses, but it's not the only thing they share, nor is it it the indicator that they are shared (that's the a=group:BUNDLE list). So the top-line category isn't shared vs/unique IP address but rather bundled vs. unbundled.

Correct.

The best thing, as far as the address in the m- line is concerned, would be to simply use normal SDP procedures (read: unique addresses) also for bundled m- lines. And, if the offerer wants to make sure a mid-session added m- line gets accepted in the bundle group (or otherwise is rejected) he would use bundle-only – in the same way it’s used in the initial offer.

Then a “shared address” would only be a property of the BUNDLE group – not related to the address put in the m- line.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Oct 2016 16:08:12 -0700

On Mon, Oct 3, 2016 at 1:07 PM, Christer Holmberg <
[email-masked]> wrote:

> The best thing, as far as the address in the m- line is concerned, would
> be to simply use normal SDP procedures (read: unique addresses) also for
> bundled m- lines. And, if the offerer wants to make sure a mid-session
> added m- line gets accepted in the bundle group (or otherwise is rejected)
> he would use bundle-only – in the same way it’s used in the initial offer.
>
>
>
> Then a “shared address” would only be a property of the BUNDLE group – not
> related to the address put in the m- line.
>

I worry that we're not communicating. I would have this document never
refer to "shared" or "unique" addresses and instead refer to bundled or
unbundled m= lines.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Oct 2016 23:14:38 +0000

Hi,

OVERALL

Correct.

I worry that we're not communicating. I would have this document never refer to "shared" or "unique" addresses and instead refer to bundled or unbundled m= lines.

Earlier you said that “shared address” is one of the PROPERTIES of a bundled m- line, and that is what I was referring to. Other than that, we would not have to talk about “shared” or “unique” addresses, as you suggest.

“BUNDLED m= lines are grouped together and share a bunch of properties. Amongst those properties is that they share IP addresses,”

Regards,

Christer