Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments

From: Christer Holmberg <[email-masked]>
Date: Sat, 18 Oct 2014 19:51:44 +0000

Hi Paul,

Thanks for your review! See inline.

-------------------------

>*< Abstract:
>
>The following language is a little awkward:
>
>    Both endpoints can negotiate the use of bundle and to support that
>    negotiations, this specification ...
>
>How about the following:
>
>    To assist endpoints in negotiating the use of bundle this
>    specification ...

OK.

> In the same paragraph, s/allows/allow/

OK.

-------------------------

>* Section 1: Introduction:
>
>In the third paragraph is:
>
>    The BUNDLE address is used to send and receive
>    all media associated with the BUNDLE group.
>
>In the above, s/address is/addresses are/

OK.

-------------------------

>The 6th paragraph says:
>
>    This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264
>    [RFC3264].  The update allows an answerer to assign a non-zero port
>    value to an "m=" line in an SDP answer, even if the "m=" line in the
>    associated SDP offer contained a zero port value.
>
>The statement of the update is overly broad, because it doesn't state that the relaxation on answering with a non-zero port only applies within a bundle. I suggest the following:
>
>    This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264
>    [RFC3264].  The update allows an answerer to assign a non-zero port
>    value to a bundled "m=" line in an SDP answer, even if the "m=" line
>    in the associated SDP offer contained a zero port value.

I can do that change, but keep in mind that the new RFC 3264 text does not talk about BUNDLE, but more generically say that an extension can define new semantics for a port zero value in an offer.

-------------------------

>* Section 2: Terminology
>
>In the following:
>
>    BUNDLE group: A set of "m=" lines, created using an SDP Offer/Answer
>    exchange, for which each endpoint uses a single 5-tuple to send and
>    receive media.  Each endpoint uses its BUNDLE address, associated
>    with the BUNDLE group, to send and receive the media.
>
> are we *requiring* symmetric media usage? Certainly you must *receive* on your bundle address, but AFAIK *sending* on that address is, in general, optional though various options that > might be used with it (such as ICE) may require it.

The definition of "BUNDLE address" states that the address is used for both sending and receiving media.

-------------------------

>* Section 6: SDP 'bundle-only' Attribute
>
>I would like to see the definition follow the new style introduced in draft-ietf-mmusic-rfc4566bis-12. This draft is nearer to completion to that one, and there is some risk that the new style >will be revised in that draft. I don't propose to hold this draft up for that one - there should not be any formal dependency.

I'll look into that.

One comment, that I will provide in a separate e-mail, I have on the new style is that it should define (or, at least refer to) the Offer/Answer procedures for the attribute.

-------------------------

>* Section 7.3: Bandwidth
>
>Says:
>
>    The total proposed bandwidth for a BUNDLE group is the sum of the
>    proposed bandwidth for each bundled "m=" line.
>
>What if some of the bundled m-lines have no b= line, while others do? It probably doesn't make sense to treat them as having zero bandwidth. I guess maybe some default value should be >used. But what?

You do whatever you'd do for a non-BUNDLED "m=" line. Normally I guess you have a default value, or a value based on the media type and/or payload formats.

>Or, I guess there could be a rule that if any of the bundled m-lines have b= then all of them must.
>
>Also, I guess there needs to be a separate sum for each bandwidth type.
>
>Note: this is also an issue for draft-ietf-mmusic-sdp-mux-attributes.
>
>I note that section 7.3 defers to draft-ietf-mmusic-sdp-mux-attributes
>for attribute bundling rules. 

I assume you mean section 7.4?

>Perhaps this section should similarly defer to that draft for bandwidth bundling.

The "b=" parameter is not covered by that draft (as it's not an SDP attribute).

-------------------------

>* Section 8.2.1: Generating the Initial SDP Offer: General
>
>The use of "assign" in the second bullet item seems inappropriate:
>
>    o  Assign an SDP 'group:BUNDLE' attribute to the offer;
>
>I suggest instead:
>
>    o  Add a new SDP 'group:BUNDLE' attribute to the offer
>       for the new BUNDLE group;

OK.

-------------------------

>* Section 8.2.2: Request offerer BUNDLE address selection
>
>I think the name of this section is slightly confusing - "Request" could be a verb (intended) or a noun. I suggest changing it to:
>
>"Suggesting an offerer BUNDLE address"

I use "Request" in other places (e.g. "offerer requested the BUNDLE group") so I'd like to keep the text.

In addition, aren't you the one who suggested "Request" terminology in the past? :)

-------------------------

>* Section 8.3.2: Answerer Selection of Offerer Bundle Address
>
>I have a few wording changes to suggest for clarity:
>
>In this section, the use of 'the "m=" line' seems a little vague. I think it would be better to change it to 'that "m=" line' throughout.

I do agree that we could use the following modified sentence:

	"The answerer MUST check whether that "m=" line fulfils the following criteria:"

But, after that, I think all instances of 'the' refers to that 'that' :)

>Also
>- s/fulfils/fulfills/
>- s/criteria above is fulfilled/criteria above are fulfilled/
>- s/criteria is not fulfilled/criteria are not fulfilled/
>- s/represents/identifies/

OK.

-------------------------

>* Section 8.4.1: Offerer Processing of the SDP Answer: General
>
>In the following:
>
>    When an offerer receives an answer, if the answer contains a BUNDLE
>    group, the offerer MUST check that any bundled "m=" line in the
>    answer was indicated as bundled in the associated offer.  If there is
>    no mismatch, the offerer MUST apply the offerer BUNDLE address,
>    selected by the answerer [Section 8.3.2], to each bundled "m=" line.
>
> the use of the word "apply" is a little unclear. While the intent can be inferred, it isn't defined anywhere, or used in this way anywhere else. 
>I suggest it could be written as:
>
>    ... the offerer MUST use the offerer BUNDLE address, selected by
>    the answerer [Section 8.3.2], as the address for each bundled
>    "m=" line.

OK.

-------------------------

>* Section 9.2: STUN, DTLS, SRTP
>
>In the first paragraph, s/offer or answerer/offerer or answerer/

OK.

>Replace the following:
>
>   ... If an offer or answerer in offers or answers include
>    bundled "m=" lines that represent these protocols, the offerer or
>    answerer MUST support ...
>
>with:
>
>    ... If an offer or answer includes bundled "m=" lines that represent
>    these protocols, the offerer or answerer MUST support ...

OK.

>Another thing: I *think* that *plain* RTP can also coexist with STUN, DTLS, and SRTP using the rules of RFC5764. (Can somebody confirm if this is true?)

I'll ask Colin.

>Also, there is *no* mention of SCTP in this document. ISTM that there should be something. I guess the 2nd paragraph here is intended to cover that. If so, it is too subtle.

The document does not cover SCTP - unless it is transported on top of DTLS, in which case it is implicitly covered by the 2nd paragraph.

What would you like to mention about SCTP?

>IIUC, DTLS/SRTP uses DTLS packets to do key exchange, but doesn't use DTLS payload packets. So *one* m-line with a protocol that uses DTLS payload packets (e.g., >DTLS/SCTP) can coexist with STUN and SRTP. If there is more than one such m-line then some other specification is required to associate those packets with m-lines.

I think that is covered, as SRTP is distinguished from DTLS.

But, if you think that needs to be more clear, maybe the following modified sentence:

	"[RFC5764] does not describe how to identify different protocols transported on DTLS (i.e. using DTLS payload packets), only how to..."

-------------------------

>* Section 10.1.1: Single RTP Session: General
>
>The second bullet:
>
>    o  The "proto" value in each bundled "m=" line MUST be identical
>       (e.g.  RTP/AVPF).
>
>should only apply to RTP m-lines. E.g.:
>
>    o  The "proto" value in each bundled RTP-based "m=" line MUST be
>       identical (e.g.  RTP/AVPF).

OK.

-------------------------

>* 10.3.2.2: Generating the Initial SDP Offer
>
>Similar comment to the previous one:
>
>   s/each bundled "m=" line/each bundled RTP-based "m=" line/
>
>(It occurs twice in the paragraph.)

OK.

-------------------------

>* 10.3.2.3: Generating the SDP Answer
>
>My comment for 10.3.2.2 applies here as well.

OK.

>The MUST NOT in the 2nd paragraph concerns me:
>
>    If the answerer accepts usage of RTP/RTCP multiplexing within the
>    BUNDLE group, it MUST assign an SDP 'rtcp-mux' attribute to each
>    bundled "m=" line in the answer.  The answerer MUST NOT assign an SDP
>    'rtcp' attribute to any bundled "m=" line in the answer.  The
>    answerer will use the port number of the selected offerer BUNDLE
>    address for sending RTP and RTCP packets associated with each bundled
>    "m=" line towards the offerer.
>
>I don't understand why the rtcp attribute MUST NOT be used. I understand that the port from the offer is 
>used by the answerer to send RTCP. But without the attribute there is no explicit indication of where the 
>offerer is to send RTCP. What is wrong with including the rtcp attribute in the answer???
>
>Also, in general (ignoring bundle), isn't it valid to use the 'rtcp' attribute without the 'rtcp-mux'? (I thought 
>it was invented for cases where NATs prevented getting an even/odd pair of ports.) So in bundle, shouldn't 
>it also be valid to use the 'rtcp' attribute without the 'rtcp-mux' attribute? (Identical in all m-lines.)

The reason we don't allow 'rtcp' in the answer (even if RTP/RTCP multiplexing is not used) is because in the offer we only allow the value of the "m=" line (i.e. the value used for RTP) for 'rtcp'. 

So, either multiplexing is used, or port+1 is used. If we'd change that, we should also allow the offerer to assign whatever value it wants to the 'rtcp' attribute...

-------------------------

>* Section 12: Update to RFC 3264
>
>The way in which the changes are presented are great for somebody who is not familiar with 3264 and is truly reading this instead. (Or for somebody who is authoring >3264bis.) But it is quite difficult to understand what the differences are between the two. I had to copy the text out into separate old and new files and then diff them to >clearly understand what has changed.
>
>I'd appreciate some sort of diff that highlights the fundamental distinctions. (But I'm not sure what kind would be clear and work with the constraints of a draft.)

The Introduction states that the change is related to the usage of port zero, so having that information I think it is not that difficult to see what has been changed.

Also, my experience from the IESG reviews is that there are always different suggestions on how to update text. So, I'd prefer to keep it as it is, because it may still come up as part of the IESG review.

-------------------------

>* Section 12.5: New text replacing section 8.2 (2nd paragraph)
>
>I take issue with one change here - the addition of "(like the offer)". 
>I don't know if you intend it that way, but to me it seems to suggest that you can only omit attributes if they were omitted in the offer.
>
>So I think that particular part of the change should be removed.

The intention is not to indicate that one can only omit attributes if they were omitted in the offer.

I am ok to remove "(like the offer)".

-------------------------

>* Section 16: Examples
>
>The ordering of fields in the examples in not valid according to the rules of 4566. It requires "c=", "b=", "a=" in that order.

OK.

The examples were provided by Harald, so I hope they are not based on a Chrome trace ;)

-------------------------

>* Section 16.3
>
>I gather that this example is intended to continue on from the the example in 16.1. It would be helpful to say that.

OK.

-------------------------

>* Section 16.4
>
>I gather that this example is intended to continue on from the the example in 16.3. It would be helpful to say that.

OK.

-------------------------

>* Section 16.5
>
>I gather that this example is intended to continue on from the the example in 16.3. It would be helpful to say that.

OK.

-------------------------

Thanks!

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Oct 2014 13:01:05 -0400

Replies inline

> Thanks for your review! See inline.

Good point. While this statement is overly broad, it is only an 
overview, and the sections that formally update 3264 are more specific. 
So I take back this suggestion.

This is a little fuzzy. That is mentioned in the Intro, but not in the 
Terminology definitions of Offerer/Answerer BUNDLE address. It is 
mentioned in the definition of BUNDLE group, but not in a normative way.

If you really intend to require this, then it should be stated more 
clearly in a normative way.

I think this requires discussion with people that know more about this 
topic.

AFAIK, with non-bundled m-lines that don't specify, there is no specific 
limit unless there is a session-level b-line. I don't know what happens 
if there is a session-level b-line. I guess there is supposed to be a 
default for every codec.

> I assume you mean section 7.4?

Yup.

> The "b=" parameter is not covered by that draft (as it's not an SDP attribute).

Ah! So this draft is on its own. It seems like more text is needed. 
Especially what to do with extension bandwidth types.

I don't remember. In any case it is a hard statement to parse. If you 
want to keep the term, how about "Requesting offerer BUNDLE address 
selection"? (But I still think "Suggesting" is clearer.)

s/fulfils/fulfills/

OK.

>> - s/represents/identifies/

Sounds good.

> 	"[RFC5764] does not describe how to identify different protocols transported on DTLS (i.e. using DTLS payload packets), only how to..."

I think this document should bite the bullet and define how SCTP 
coexists with SRTP in a bundle.

OK.

OK.

Thanks.

	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Oct 2014 09:44:03 +0000

Hi,

>>> are we *requiring* symmetric media usage? Certainly you must *receive* on your bundle 
>>> address, but AFAIK *sending* on that address is, in general, optional though various 
>>> options that might be used with it (such as ICE) may require it.
>>
> This is a little fuzzy. That is mentioned in the Intro, but not in the Terminology definitions of Offerer/Answerer 
> BUNDLE address. It is mentioned in the definition of BUNDLE group, but not in a normative way.
>
> If you really intend to require this, then it should be stated more clearly in a normative way.

I checked the definitions for "Offerer BUNDLE address" and "Answerer BUNDLE address", and you are correct that the text only talks about receiving media.

So, that would have to be fixed.

...unless, of course, we'd choose to NOT mandate symmetric media (obviously, the sender would still need to use a single address:port for sending all media associated with the BUNDLE group).

>>> What if some of the bundled m-lines have no b= line, while others do? It probably 
>>> doesn't make sense to treat them as having zero bandwidth. I guess maybe some 
>>> default value should be used. But what?
>>
>> You do whatever you'd do for a non-BUNDLED "m=" line. Normally I guess you have 
>> a default value, or a value based on the media type and/or payload formats.
>
> I think this requires discussion with people that know more about this topic.

I think we had discussions about this in the past, and the outcome was that you calculate the bandwidth in the same way as you would for non-bundled m- lines.

> AFAIK, with non-bundled m-lines that don't specify, there is no specific limit unless there 
> is a session-level b-line. I don't know what happens if there is a session-level b-line. I guess there is supposed to be a default for every codec.

I don't think it's up to the BUNDLE spec to define what a missing b- line means.

> Especially what to do with extension bandwidth types.

I'm not really sure what text would have to be added, so I'd need some input on that.

> I don't remember. In any case it is a hard statement to parse. If you want to keep the term, how 
> about "Requesting offerer BUNDLE address selection"? (But I still think "Suggesting" is clearer.)

Then we would have to change the section 8.5.2 title ("Request a new offerer BUNDLE address") too.

And, in section 8.5.1 there is a sentence saying:

   "o  The offerer wants to request the answerer to select a new offerer
      BUNDLE address [Section 8.5.2];"

And, there is other text where "request" is used, e.g. when talking about requesting a BUNDLE group to be created etc.

Etc.

One option, which is also more aligned with the 8.5.2 title, would be to say:

	"Request an offerer BUNDLE address"  (or "Request the offerer BUNDLE address")

...i.e. add "an" (or "the") and remove "selection". 

>> 	"The answerer MUST check whether that "m=" line fulfils the following criteria:"

Correct.

>>> - s/represents/identifies/

Here I'd actually like to keep "represents", because that is the wording used elsewhere in the document.

>>> Another thing: I *think* that *plain* RTP can also coexist with STUN, 
>>> DTLS, and SRTP using the rules of RFC5764. (Can somebody confirm if 
>>> this is true?)
>>
>> I'll ask Colin.
>
> Sounds good.

I've sent him an e-mail.

>>> Also, there is *no* mention of SCTP in this document. ISTM that there should be 
>>> something. I guess the 2nd paragraph here is intended to cover that. If so, it is too subtle.
>>
>>> IIUC, DTLS/SRTP uses DTLS packets to do key exchange, but doesn't use DTLS payload 
>>> packets. So *one* m-line with a protocol that uses DTLS payload packets (e.g., >DTLS/SCTP) can 
>>> coexist with STUN and SRTP. If there is more than one such m-line then some other specification is 
>>> required to associate those packets with m-lines.
>>
> I think this document should bite the bullet and define how SCTP coexists with SRTP in a bundle.

Personally, I would not want to do that at this stage. We decided earlier that the draft will cover DTLS, SRTP and STUN, and that any other protocols/combinations have to be defined elsewhere.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Oct 2014 11:48:13 -0400

Christer,

More inline.

> Hi,

In general I prefer not to impose unnecessary restrictions. So unless 
there is come compelling reason to require symmetric media I would 
rather not. Of course some usages (e.g., ICE) will still require it, but 
that is up to them, not bundle.

But I'm willing to listen to reasons why this is required for bundle.

If bundle forces a new concern, where there was none in the past, then 
bundle needs to say what to do about it.

So I think *something* needs to be said. It might not be complicated.

The current text says to sum the bandwidth across all the m-lines in the 
bundle. At the least, it should say that the sum must be done separately 
for bandwidth types CT and AS, and if any other types have been defined 
then for them too.

I don't really understand these, or how they are used. From reading 4566 
I *think* that CT is only used at session level. If so, then it is not a 
concern for bundle. So that should be stated (if it is true).

So maybe it is only AT type that can appear in a bundle.

I don't find anything in 4566 about summing bandwidth values across 
m-lines. It says "CT gives a total bandwidth figure for all the media at 
all sites", but I don't think there is any expectation that the sum of 
the AT values for individual m-lines are bounded by that. My impression 
is that it might be quite reasonable for that sum to exceed the CT 
value, because they may not all be used concurrently.

I'm out of my depth regarding bandwidth specification and enforcement. 
Can we get somebody who knows about this stuff to comment?

I'm just going to give up on this. It isn't important enough to devote 
this much effort to.

OK.

If it isn't here, then it needs to be somewhere else. Where?

It shouldn't be hard.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Oct 2014 16:29:27 +0000

Hi Paul,

See inline.

>>>>> are we *requiring* symmetric media usage? Certainly you must 
>>>>> *receive* on your bundle address, but AFAIK *sending* on that 
>>>>> address is, in general, optional though various options that might be used with it (such as ICE) may require it.
>>>>
>>> This is a little fuzzy. That is mentioned in the Intro, but not in 
>>> the Terminology definitions of Offerer/Answerer BUNDLE address. It is mentioned in the definition of BUNDLE group, but not in a normative way.
>>>
>> ...unless, of course, we'd choose to NOT mandate symmetric media (obviously, the sender would 
>> still need to use a single address:port for sending all media associated with the BUNDLE group).
>
> In general I prefer not to impose unnecessary restrictions. So unless there is come compelling reason to require 
> symmetric media I would rather not. Of course some usages (e.g., ICE) will still require it, but that is up to them, not bundle.
>

I don't remember whether we ever discussed that. Perhaps people have had that assumption, since the biggest customer of BUNDLE so far has been RTCWEB, where usage of ICE is mandatory.

So, let's try to get some input from others.

>>>>> What if some of the bundled m-lines have no b= line, while others 
>>>>> do? It probably doesn't make sense to treat them as having zero 
>>>>> bandwidth. I guess maybe some default value should be used. But what?
>>>>
>>>> You do whatever you'd do for a non-BUNDLED "m=" line. Normally I 
>>>> guess you have a default value, or a value based on the media type and/or payload formats.
>>>
>>> AFAIK, with non-bundled m-lines that don't specify, there is no 
>>> specific limit unless there is a session-level b-line. I don't know what happens if there is a session-level b-line. I guess there is supposed to be a default for every codec.
>>
> If bundle forces a new concern, where there was none in the past, then bundle needs to say what to do about it.
>
> The current text says to sum the bandwidth across all the m-lines in the bundle. At the least, it 
> should say that the sum must be done separately for bandwidth types CT and AS, and if any other 
> types have been defined then for them too.
>
> I don't really understand these, or how they are used. From reading 4566 I *think* that CT is only 
> used at session level. If so, then it is not a concern for bundle. So that should be stated (if it is true).
>
> I don't find anything in 4566 about summing bandwidth values across m-lines. It says "CT gives a total 
> bandwidth figure for all the media at all sites", but I don't think there is any expectation that the sum 
> of the AT values for individual m-lines are bounded by that. My impression is that it might be quite 
> reasonable for that sum to exceed the CT value, because they may not all be used concurrently.
>

Yeah, I think we need input and guidance from the media plane folks here :)

>>>>> Also, there is *no* mention of SCTP in this document. ISTM that 
>>>>> there should be something. I guess the 2nd paragraph here is intended to cover that. If so, it is too subtle.
>>>>
>>>>> IIUC, DTLS/SRTP uses DTLS packets to do key exchange, but doesn't 
>>>>> use DTLS payload packets. So *one* m-line with a protocol that uses 
>>>>> DTLS payload packets (e.g., >DTLS/SCTP) can coexist with STUN and 
>>>>> SRTP. If there is more than one such m-line then some other specification is required to associate those packets with m-lines.
>>>>
>> Personally, I would not want to do that at this stage. We decided earlier that the draft will cover 
>> DTLS, SRTP and STUN, and that any other protocols/combinations have to be defined elsewhere.
>

In a separate draft.

> It shouldn't be hard.

Who is asking for it? RTCWEB will not support SCTP transport (they will support SCTP over DTLS).

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Oct 2014 13:09:05 -0400

> Who is asking for it? RTCWEB will not support SCTP transport (they will support SCTP over DTLS).

I'll be satisfied if it covers SCTP over DTLS. That is the case where it 
needs to be able to coexist with RTP.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Oct 2014 09:56:05 +0000

Hi,

>>>>>>> use DTLS payload packets. So *one* m-line with a protocol that 
>>>>>>> uses DTLS payload packets (e.g., >DTLS/SCTP) can coexist with 
>>>>>>> STUN and SRTP. If there is more than one such m-line then some other specification is required to associate those packets with m-lines.
>>>>>>
>>>> Personally, I would not want to do that at this stage. We decided 
>>>> earlier that the draft will cover DTLS, SRTP and STUN, and that any other protocols/combinations have to be defined elsewhere.
>>>
> I'll be satisfied if it covers SCTP over DTLS. That is the case where it needs to be able to coexist with RTP.

The draft describes how you distinguish between DTLS and SRTP, so that also covers SCTP over DTLS (SCTP is the "application protocol" carried on DTLS).

How you differentiate different protocols carried over DTLS need to be described elsewhere, but if you only have SCTP carried over DTLS nothing else is needed.

In addition, if you want to define how to separate SCTP from something else, you would need to know what that something else is.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Oct 2014 10:30:28 -0400

> In addition, if you want to define how to separate SCTP from something else, you would need to know what that something else is.

The draft describes how to distinguish DTLS and SRTP packets. It doesn't 
describe how to associate the DTLS packets with m-lines.

Rather than single SCTP over DTLS out as special, this draft could 
simply say that:

- if the bundle contains *no* m-lines for protocols that utilize DTLS
   payload packets then DTLS payload packets are erroneous.

- if the bundle contains *one* m-line for a protocol that utilizes
   DTLS payload packets then all the payload packets are to be
   associated with it.

- if the bundle contains *more than one* m-line for protocols that
   utilize payload packets then some other specification is needed
   to define how the packets are associated with m-lines.

	Thanks,
	Paul