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

[Paul Kyzivat <[e-mail]>]

Christer,

More inline.

On 10/21/14 5:44 AM, Christer Holmberg wrote:
> Hi,
>
> -------------------------
>
>>>> * 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.
>>
>> 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).

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.

> -------------------------
>
>>>> * 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.
>>
>> 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.

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.

> -------------------------
>
>>>> 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?
>>
>> Yup.
>>
>>>> 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).
>>
>> Ah! So this draft is on its own. It seems like more text is needed.
>> 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.

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?

> -------------------------
>
>>>> * 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? :)
>>
>> 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".

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

> -------------------------
>
>>>> * 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:"
>>
>> s/fulfils/fulfills/
>
> Correct.
>
>>>> 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.
>
> Here I'd actually like to keep "represents", because that is the wording used elsewhere in the document.

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.
>>
>> 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.
>>>
>>> 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..."
>>
>> 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.

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

It shouldn't be hard.

	Thanks,
	Paul