Subject: [MMUSIC] bandwidth recommendation removed from draft-ietf-mmusic-sdp-capability-negotiation-12

From: "Roni Even" <[email-masked]>
Date: Wed, 24 Mar 2010 01:45:20 +0200

Hi,

I noticed that the new version removed recommendation to use the TIAS
bandwidth type[RFC3890]. 
My view according to RFC 3264 is that in offer answer cases which this work
address states that "for unicast streams If the bandwidth attribute is
present for a stream, it indicates the  desired bandwidth that the offerer
would like to receive" and "The answerer MAY include a bandwidth attribute
for any media stream;   this indicates the bandwidth that the answerer would
like the offerer  to use when sending media."
 
It does not differentiate between the different attributes (AS, CT, TIAS) so
I am not sure why this recommendation was removed
 
Thanks
Roni Even

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 25 Mar 2010 16:02:46 -0700

Hi Roni

As explained in Section 3.10 of the draft:
<quote>
[RFC3264] defines the bandwidth
    parameter to apply to the receive direction for unicast streams,
    whereas [RFC3890] intends to use bandwidth in the send direction.
</quote>

It is this semantic inconsistency that makes it ambiguous as to what 
TIAS actually means (which direction is it ?). Based on this, Magnus 
recommended against using TIAS in here and hence the update you see.

Thanks

-- Flemming

As explained in the draft, there seems to be inconsistent semantics wrt 
to directionality of the

On 3/23/10 4:45 PM, Roni Even wrote:
> Hi,
>
> I noticed that the new version removed recommendation to use the TIAS bandwidth type[RFC3890].
> My view according to RFC 3264 is that in offer answer cases which this work address states that "for unicast streams If the bandwidth attribute is present for a stream, it indicates the  desired bandwidth that the offerer would like to receive" and "The answerer MAY include a bandwidth attribute for any media stream;   this indicates the bandwidth that the answerer would like the offerer  to use when sending media."
>
> It does not differentiate between the different attributes (AS, CT, TIAS) so I am not sure why this recommendation was removed
>
> Thanks
> Roni Even
>
>

---

From: "Roni Even" <[email-masked]>
Date: Fri, 26 Mar 2010 18:22:00 +0300

Hi Flemming,
Here is when I disagree. 
The capability negotiation is used in the contents of offer answer and not
for declarative SDP or other usages. In this case RFC3264, which is the
offer answer specification and is an MMUSIC document, states that for this
case the bandwidth parameter for unicast is a receive capability.

Based on this language there are implementations that use TIAS as receive
capability in unicast offer answer case. The new text says that the text in
RFC 3264 is not correct. So either we change RFC 3264 or what the current
text in capability negotiation that says that TIAS cannot be used.

BTW: I did not see in RFC3890 any language that says that TIAS MUST be used
for send direction only. This is why implementations in offer answer case
are using this parameter based on the language of RFC 3264.

My suggestion is to remove the whole paragraph and Magnus can ask to update
RFC 3264 if TIAS should not be used for receive direction in offer answer
case.

Roni Even

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Friday, March 26, 2010 1:03 AM
> To: Roni Even
> Cc: [email-masked]
> Subject: Re: [MMUSIC] bandwidth recommendation removed fromdraft-ietf-
> mmusic-sdp-capability-negotiation-12
> 
> Hi Roni
> 
> > My view according to RFC 3264 is that in offer answer cases which
> this work address states that "for unicast streams If the bandwidth
> attribute is present for a stream, it indicates the  desired bandwidth
> that the offerer would like to receive" and "The answerer MAY include a
> bandwidth attribute for any media stream;   this indicates the
> bandwidth that the answerer would like the offerer  to use when sending
> media."
> >
> > It does not differentiate between the different attributes (AS, CT,
> TIAS) so I am not sure why this recommendation was removed
> >
> > Thanks
> > Roni Even
> >
> >

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 26 Mar 2010 09:24:10 -0700

There was a long thread in AVT back in January 2007 (titled "CCM draft 
review -- should "bandwidth" include the header    overhead") which gets 
into the inconsistency issues between RFC 3264 and RFC 3890. While there 
may be implementations out there that have interpreted things 
differently, I think the conclusion of the above thread remains and 
hence the text that was added in sdp-cap-neg on this should remain as well.

Let's see what Magnus says, since he's the author of RFC 3890 and the 
person to raise the issue wrt the original SDPcapneg text that actually 
suggested use of RFC 3890 (I was not aware of the issue Magnus pointed 
out, and I suspect others aren't either and hence it's good to capture 
the problem in here rather than being silent on it).

Thanks

-- Flemming

---

From: "Roni Even" <[email-masked]>
Date: Fri, 26 Mar 2010 20:53:29 +0300

Flemming,

The thread on CCM did not discuss any inconsistency between RFC 3264 and RFC
3890. It discussed the issue of how to define the TMMBR value in CCM. The
definition of TIAS and RFC 3264 still holds and the deployment of the video
conferencing solutions is using it usually with the AS value to provide the
maximum codec bit rate supported. 

The following text provides the current status of video conferencing
interoperating implementations .

"There is a need to signal the bandwidth corresponding to each video stream
in the SDP. 

 The TIAS (RFC 3890) and AS (RFC 4566) bandwidth specifiers should be used
as shown in the following example. Use of TIAS bandwidth specifier at the
session level and the video m line level is mandatory. It is recommended
that AS bandwidth specifier also be used at the session level for backward
compatibility.

Notes:

The maximum receive bandwidth specified in an SDP answer can be different
from the bandwidth specified in the corresponding SDP offer.

For an audio stream (or when the bandwidth is implied by the codec used),
bandwidth signalling at the corresponding media level is not necessary and
is therefore not recommended.  If no bandwidth parameter (b=) is present at
the session level, then a bandwidth parameter must be present at every media
level where needed."

Roni Even

From: Flemming Andreasen [mailto:[email-masked]] 
Sent: Friday, March 26, 2010 7:24 PM
To: Roni Even
Cc: [email-masked]; Magnus Westerlund
Subject: Re: [MMUSIC] bandwidth recommendation removed
fromdraft-ietf-mmusic-sdp-capability-negotiation-12

There was a long thread in AVT back in January 2007 (titled "CCM draft
review -- should "bandwidth" include the header    overhead") which gets
into the inconsistency issues between RFC 3264 and RFC 3890. While there may
be implementations out there that have interpreted things differently, I
think the conclusion of the above thread remains and hence the text that was
added in sdp-cap-neg on this should remain as well. 

Let's see what Magnus says, since he's the author of RFC 3890 and the person
to raise the issue wrt the original SDPcapneg text that actually suggested
use of RFC 3890 (I was not aware of the issue Magnus pointed out, and I
suspect others aren't either and hence it's good to capture the problem in
here rather than being silent on it). 

Thanks 

-- Flemming 

Hi Flemming,
Here is when I disagree.

Roni Even

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 26 Mar 2010 11:14:19 -0700

On 3/26/10 10:53 AM, Roni Even wrote:
> Flemming,
>
> The thread on CCM did not discuss any inconsistency between RFC 3264 and RFC 3890.
Sure it did. Look at the following e-mail from Magnus on 1/26/07:
<quote>
Hi,

Sorry for the delayed response. Had to do some IESG reviews.

Desineni, Harikishan skrev:
>> I also would like to say that I agree with Guido Franceschini thatTIAS
>> is flawed in this regard. TIAS only works for declarative usages of SDP.
>> TIAS is a media sender property. It doesn't work with SDP offer/answer
>> as that requires one to describe the bitrate available to receive with.
>> Thus RFC 3890 should be updated to address these issues.
>
> I am somewhat confused here. Per 3890, TIAS is a receive parameter and
> TIAS semantics for offer/answer are the same as those used for AS.
>> From Sec 5.8, RFC4566 
> "AS The bandwidth is interpreted to be application specific (it will
>       be the application's concept of maximum bandwidth)."
>
>> From Sec 5.1, RFC3264
> "If the bandwidth attribute is present for a stream, it indicates the
>    desired bandwidth that the offerer would like to receive."
>
>

Yes, I know it is specified in that way. But the reality is that TIAS 
does not work for SIP offer/answer. TIAS is only usable as a stream 
property parameter. The reason is that a receiver can't really know what 
packet rate it will use. Thus what seems possible to do to go beyond AS 
is to specify the available receiver bit-rate and the expected per 
packet overhead between for IP/UDP when using RTP.
</quote>

> It discussed the issue of how to define the TMMBR value in CCM. The definition of TIAS and RFC 3264 still holds and the deployment of the video conferencing solutions is using it usually with the AS value to provide the maximum codec bit rate supported.
>
>    
I understand that there may be a difference between what the specs say 
and what is actually deployed. In any case, let's wait for Magnus to 
comment here.

Thanks

-- Flemming

>
>
> The following text provides the current status of video conferencing interoperating implementations .
>
>
>
> "There is a need to signal the bandwidth corresponding to each video stream in the SDP.
>
>   The TIAS (RFC 3890) and AS (RFC 4566) bandwidth specifiers should be used as shown in the following example. Use of TIAS bandwidth specifier at the session level and the video m line level is mandatory. It is recommended that AS bandwidth specifier also be used at the session level for backward compatibility.
>
> Notes:
>
> The maximum receive bandwidth specified in an SDP answer can be different from the bandwidth specified in the corresponding SDP offer.
>
> For an audio stream (or when the bandwidth is implied by the codec used), bandwidth signalling at the corresponding media level is not necessary and is therefore not recommended.  If no bandwidth parameter (b=) is present at the session level, then a bandwidth parameter must be present at every media level where needed."
>
>
>
> Roni Even
>
>
>
> Subject: Re: [MMUSIC] bandwidth recommendation removed fromdraft-ietf-mmusic-sdp-capability-negotiation-12
>
>
>
> There was a long thread in AVT back in January 2007 (titled "CCM draft review -- should "bandwidth" include the header    overhead") which gets into the inconsistency issues between RFC 3264 and RFC 3890. While there may be implementations out there that have interpreted things differently, I think the conclusion of the above thread remains and hence the text that was added in sdp-cap-neg on this should remain as well.
>
> Let's see what Magnus says, since he's the author of RFC 3890 and the person to raise the issue wrt the original SDPcapneg text that actually suggested use of RFC 3890 (I was not aware of the issue Magnus pointed out, and I suspect others aren't either and hence it's good to capture the problem in here rather than being silent on it).
>
> Thanks
>
> -- Flemming
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 26 Mar 2010 11:34:26 -0700

> RFC 3264 if TIAS should not be used for receive direction in offer answer

Roni,

TIAS was not defined for Offer/Answer usage and there are clearly
unclarities in how to interpret a TIAS value in a receiver direction
which is what standard O/A interpretation would mean.

We have had this discussion earlier as Flemming points out and the only
clear conclusion we reached was that RFC 3890 should be updated if
expected to be used O/A context in a consistent way.

And I raised this issue on the capneg document in IESG review and
requested that we resolve it by removing TIAS from the document.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Roni Even" <[email-masked]>
Date: Fri, 26 Mar 2010 23:22:02 +0300

Magnus,
I have no problem with removing the whole paragraph from the capneg document
since I do not agree with the current text. 
In video conferencing systems TIAS is used in the media session for the
video codec by the receiver to specify the video decoder maximum rate while
AS is also specified on the session level for total bandwidth.

This is used in almost all video conferencing application and capneg used
for conversional video conferencing should not take it out. 

In AVT the discussion was also about if the parameter is for congestion on
the wire or to provide the codec capability and I thought that people
thought that if this work is called codec control it should mean the second.
Since the only way to provide codec level is using TIAS and since RFC3264
allows that, this was chosen as the way to do it in the video conferencing
systems.

TMBBR says that it should not use to change the rate to go over the one
specified in the b= line and I still think that since there are no common
definition for comparing which is not based on the average media bit rate
that any other method may not be good enough.
Roni 

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Friday, March 26, 2010 9:34 PM
> To: Roni Even
> Cc: 'Flemming Andreasen'; [email-masked]

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 26 Mar 2010 14:55:42 -0700

If Magnus and the group are happy with removing all references to RFC 
3890 and hence be silent on this potential issue then I can certainly do 
that - let me know.

Thanks

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 26 Mar 2010 14:56:07 -0700

Thanks

-- Flemming

---

From: Jean-Francois Mule <[email-masked]>
Date: Fri, 26 Mar 2010 16:01:50 -0600

Flemming,

  Based on my review of the comments from Roni (some are quite valid) and a brief chat I had with both Roni and Magnus this morning, I believe the best is indeed to remove this text.

  We should start a separate thread on how to tackle this issue but I agree the best is to do it outside sdp cap neg.

Jean-Francois.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Flemming Andreasen
Sent: Friday, March 26, 2010 3:56 PM
To: Roni Even
Cc: Magnus Westerlund; [email-masked]
Subject: Re: [MMUSIC] bandwidth recommendation removed fromdraft-ietf-mmusic-sdp-capability-negotiation-12

If Magnus and the group are happy with removing all references to RFC 3890 and hence be silent on this potential issue then I can certainly do that - let me know.

Thanks

-- Flemming

Magnus,

> Cc: 'Flemming Andreasen'; [email-masked]<mailto:[email-masked]>
> SE-164 80 Stockholm, Sweden| mailto: [email-masked]<mailto:[email-masked]>

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 26 Mar 2010 15:03:56 -0700

Ok - I'll delete it during auth48.

Thanks

-- Flemming

On 3/26/10 3:01 PM, Jean-Francois Mule wrote:
>
> Flemming,
>
>   Based on my review of the comments from Roni (some are quite valid) 
> and a brief chat I had with both Roni and Magnus this morning, I 
> believe the best is indeed to remove this text.
>
>   We should start a separate thread on how to tackle this issue but I 
> agree the best is to do it outside sdp cap neg.
>
> Jean-Francois.
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Flemming Andreasen
> *Sent:* Friday, March 26, 2010 3:56 PM
> *To:* Roni Even
> *Cc:* Magnus Westerlund; [email-masked]
> *Subject:* Re: [MMUSIC] bandwidth recommendation removed 
> 3890 and hence be silent on this potential issue then I can certainly 
> do that - let me know.
>
> Thanks
>
> -- Flemming
>
> > Cc: 'Flemming Andreasen'; [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]>

---

From: "Roni Even" <[email-masked]>
Date: Sat, 27 Mar 2010 05:00:26 +0300

OK,

We will probably need to wait till Magnus returns from his parental leave to
address the topic

Roni

From: Jean-Francois Mule [mailto:[email-masked]] 
Sent: Saturday, March 27, 2010 1:02 AM
To: Flemming Andreasen; Roni Even
Cc: Magnus Westerlund; [email-masked]
Subject: RE: [MMUSIC] bandwidth recommendation removed
fromdraft-ietf-mmusic-sdp-capability-negotiation-12

Flemming,

  Based on my review of the comments from Roni (some are quite valid) and a
brief chat I had with both Roni and Magnus this morning, I believe the best
is indeed to remove this text.

  We should start a separate thread on how to tackle this issue but I agree
the best is to do it outside sdp cap neg.

Jean-Francois.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Flemming Andreasen

If Magnus and the group are happy with removing all references to RFC 3890
and hence be silent on this potential issue then I can certainly do that -
let me know. 

Thanks 

-- Flemming 

Magnus,

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 30 Mar 2010 11:13:30 +0200

Roni Even skrev 2010-03-27 03:00:
> OK,
> 
> We will probably need to wait till Magnus returns from his parental
> leave to  address the topic
> 

Hi,

I would recommend that the ones that are interested in RFC 3890 for O/A
should start a draft on this based on the current RFC. I don't have an
XML source for this document to share it was authored in MS word. And it
is likely to be to old for the RFC-editor to have started using XML either.

I think there is a extremely small chance that you will have completed
any update prior to me being back. So I don't worry about getting a
chance of reviewing what anyone proposes.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 30 Mar 2010 11:16:12 +0200

Hi,

Yes, I am fine with removing the whole paragraph:

   The Transport Independent Application Specific Maximum (TIAS)
   bandwidth type as defined in [RFC3890] SHOULD NOT be used to try and
   alleviate bandwidth variability concerns due to different transport
   protocols, since there are some inconsistencies between [RFC3264]
   and [RFC3890]. More specifically, [RFC3264] defines the bandwidth
   parameter to apply to the receive direction for unicast streams,
   whereas [RFC3890] intends to use bandwidth in the send direction.
   Implementers are encouraged to look for an expected future solution
   to this.

Cheers

Magnus Westerlund