Subject: Re: [AVT] I-D Action:draft-ietf-avt-rtp-g719-02.txt

From: Colin Perkins <[email-masked]>
Date: Wed, 1 Oct 2008 16:01:06 +0100

Hi,

On 17 Sep 2008, at 17:17, Magnus Westerlund wrote:
> This is a minor update that addresses a few off-line comment about  
> the update of the CBR text to be a bit less harsh. It also adds the  
> krecommendation into the formal definition which was something that  
> was missing.

I preferred the original text in Section 9. The current wording  
doesn't sufficiently emphasise the problems with the CBR parameter.  
This draft should, I think, state that "CBR mode SHOULD NOT be used  
in the public Internet" and reference RFC 3714.

Section 5.6 states that "an implementation of this payload format in  
an application using SDP is required to understand all the payload  
parameters in their SDP-mapped form", but this contradicts section  
7.1, which states that "any unspecified parameter MUST be ignored".

Other than that, I read this, and just noticed some minor editorial  
issues:

- The requirements language should be part of section 2.

- Section 3, last paragraph, "...the encoder decides on two encoding  
modes..." - should this be "...the encoder decides between two..."?

- Section 4.2, last paragraph, "Section 4.1. in AVP" would be clearer  
written "Section 4.1 of the RTP/AVP Profile".

- Section 5.2.1, clarify that the bit rate is the codec bit rate, and  
not the RTP bit rate.

- Sections 5.3 and 5.4, "ToC is extended with" leaves it slightly  
unclear how the ToC is extended. Perhaps "ToC is immediately followed  
by"?

- Section 7.1: the description of the CBR parameter should reference  
section 9.

- Section 7.2, 2nd bullet point should reference the "channels"  
parameter.

- Section 7.2.1, last bullet point, the discussion of the CBR  
parameter should reference section 9.

Cheers,
-- 
Colin Perkins
http://csperkins.org/

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 01 Oct 2008 22:34:05 +0200

Thanks for review!

Colin Perkins skrev:
>> This is a minor update that addresses a few off-line comment about the 
>> update of the CBR text to be a bit less harsh. It also adds the 
> I preferred the original text in Section 9. The current wording doesn't 
> sufficiently emphasise the problems with the CBR parameter. This draft 
> should, I think, state that "CBR mode SHOULD NOT be used in the public 
> Internet" and reference RFC 3714.

Personally I agree, I hope the ones that thought this was to harsh do 
comment on this.

> 
> Section 5.6 states that "an implementation of this payload format in an 
> application using SDP is required to understand all the payload 
> parameters in their SDP-mapped form", but this contradicts section 7.1, 
> which states that "any unspecified parameter MUST be ignored".

I think they are compatible as long as you are clear that you need to 
understand the current defined parameter. The second statement is about 
what to do with any unknown parameter that is defined in a potentially 
later version of the payload format. I will think where we should stick 
some words to make this clear.

The below seems straightforward to address.

> 
> Other than that, I read this, and just noticed some minor editorial issues:
> 
> unclear how the ToC is extended. Perhaps "ToC is immediately followed by"?
> 
> - Section 7.2, 2nd bullet point should reference the "channels" parameter.
> 
> - Section 7.2.1, last bullet point, the discussion of the CBR parameter 
> should reference section 9.
> 
> Cheers,

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: "Roni Even" <[email-masked]>
Date: Thu, 2 Oct 2008 11:14:07 +0300

Colin,
About the CBR, 
According to RFC 2119 Recommended and Should are the same. If we say SHOULD
not then we run in to the comments that says that you have to specify when
it is allowed. The current state has the meaning of should not and states
when it can be used.

Roni
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Colin
Perkins
Sent: Wednesday, October 01, 2008 6:01 PM
To: Magnus Westerlund
Cc: IETF AVT WG
Subject: Re: [AVT] I-D Action:draft-ietf-avt-rtp-g719-02.txt

Hi,

Cheers,
-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Thu, 2 Oct 2008 09:33:12 +0100

On 2 Oct 2008, at 09:14, Roni Even wrote:
> About the CBR, According to RFC 2119 Recommended and Should are the  
> same. If we say SHOULD not then we run in to the comments that says  
> that you have to specify when it is allowed.

Good! That's how I think this should be structured... by default, do  
not use this, unless you're in these very specific cases.

-- 
Colin Perkins
http://csperkins.org/

---

From: "Roni Even" <[email-masked]>
Date: Thu, 2 Oct 2008 16:17:46 +0300

Colin,
This is from the 02 version
Section 7.1

CBR:  Constant Bit Rate (CBR), indicates the exact codec-bitrate in
      bits per second (not including the overhead from packetization,
      RTP header or lower layers) that the codec MUST use.  CBR is to be
      used when dynamic rate cannot be supported (one case is e.g
      gateway to H.320).  CBR is mostly used for gateways to circuit
      switch networks.  Therefore the CBR rate is the rate not including
      any FEC as specified in Section 4.3.1.  If FEC is to be used the
      b= parameter MUST be used to allow the extra bit rate needed to
      send the redundant information.  It is RECOMMENDED that this
      parameter is only used when necessary to establish a working
      communication.
Section 9

The CBR signalling parameter allows a receiver to lock down a RTP
   payload type to use a single encoding rate.  As this prevents the
   codec rate from being lowered when congestion is experienced, the
   sender is constrained to either change the packetization or abort the
   transmission.  Since these responses to congestion are severely
   limited, it is RECOMMENDED to only use the CBR parameter in cases
   when it is necessary for establishing a working communication.

This is from the 01 version
Section 7.1

CBR:  Constant Bit Rate (CBR), indicates the exact codec-bitrate in
      bits per second (not including the overhead from packetization,
      RTP header or lower layers) that the codec MUST use.  CBR is to be
      used when dynamic rate cannot be supported (one case is e.g
      gateway to H.320).  CBR is mostly used for gateways to circuit
      switch networks.  Therefore the CBR rate is the rate not including
      any FEC as specified in Section 4.3.1.  If FEC is to be used the
      b= parameter MUST be used to allow the extra bit rate needed to
      send the redundant information.

Section 9

The CBR signalling parameter allows that a receiver locks down a RTP
   payload type to use a single encoding rate.  This have negative
   affect on the congestion control properties as it prevents the codec
   rate from be lowered when experience congestion.  Instead only
   changes to packetization are possible, thus severely reducing the
   possibility to adopt a bit-rate that meets the congestion control
   constraints.  To avoid this issue and the need to stop transmission
   of audio data the usage of CBR is NOT RECOMMENDED.

So are you OK with

The CBR signalling parameter allows a receiver to lock down a RTP
   payload type to use a single encoding rate.  As this prevents the
   codec rate from being lowered when congestion is experienced, the
   sender is constrained to either change the packetization or abort the
   transmission.  Since these responses to congestion are severely
   limited, it is NOT RECOMMENDED to use the CBR parameter except in cases
   when it is necessary for establishing a working communication (for
example when used by a gateway to H.320 systems).

Roni

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: Thursday, October 02, 2008 11:33 AM
To: Roni Even
Cc: 'Magnus Westerlund'; 'IETF AVT WG'
Subject: Re: [AVT] I-D Action:draft-ietf-avt-rtp-g719-02.txt

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Thu, 2 Oct 2008 21:18:54 +0200

Roni,

On 2 Oct 2008, at 15:17, Roni Even wrote:
...
> example when used by a gateway to H.320 systems).

The problem is "when it is necessary for establishing a working  
communication" is a very vague condition. Perhaps "Since these  
responses to congestion are severely limited, implementations SHOULD  
NOT use the CBR parameter unless they are interacting with a device  
that cannot support variable bit rate (e.g. a gateway to H.320  
systems). When using CBR mode, a receiver MUST monitor the packet  
loss rate to ensure congestion is not caused, following the  
guidelines in Section 2 of RFC 3551.".

Cheers,
Colin

---

From: "stephen botzko" <[email-masked]>
Date: Fri, 3 Oct 2008 08:14:51 +0200

Colin,

Your text appears more precise, however how does the sender know it is
interacting with such a constrained devide?

I think the answer lies in the text describing CBR as a receiver
capability.  Therefore I suggest it would be better to insert a "should not"
in the CBR parameter text indicating a device should not express the
receiver capability if it is capable of receiving a variable rate stream.

Then delete the "implementations should not" sentence you suggest, but leave
the sentence about monitoring packet loss.

Though perhaps even the last sentence on packet loss is redundant (or
over-specified), since surely packet loss monitoring and congestion control
is required for all connections, based on the first paragraph in section 9?

Or do you mean to put a more severe constraint on CBR than would be applied
to (for example)  FEC.  Since senders are not mandated to use variable rate
encoding (whether they signal CBR or not), I think it is not a good idea to
even hint that if you don't specify CBR that you don't need to worry about
congestion control.

The situation with congestion control is common to most speech codecs, whcih
tend to be fixed rate.  It seems inapproprate to make fixed rate
encoding out to be particularly evil, since that is generally the
*only*mode of operatoin that speech codecs have.  G.719 is actually
much better
for congestion control, since it makes VBR reception a requirement except in
the rare cases where CBR is needed.

Stephen Botzko

On Thu, Oct 2, 2008 at 9:18 PM, Colin Perkins <[email-masked]> wrote:

> communication" is a very vague condition. Perhaps "Since these responses to
> congestion are severely limited, implementations SHOULD NOT use the CBR
> parameter unless they are interacting with a device that cannot support
> variable bit rate (e.g. a gateway to H.320 systems). When using CBR mode, a
> receiver MUST monitor the packet loss rate to ensure congestion is not
> caused, following the guidelines in Section 2 of RFC 3551.".
>
> Cheers,
> Colin
>

---

From: "Roni Even" <[email-masked]>
Date: Fri, 3 Oct 2008 13:16:08 +0300

Steve,

I think that Colin wants this sentence in section 9 since this codec has
variable bit rate functionality and the CBR constrains contradicts
congestion. What it says is that if the codec support VBT be careful when
you ask for CBR.

For section 9 it is not important if this is a receive capability, the
importance is the constrains for CBR. This is only relevant for the
parameter definition.

I think that Colin suggestion is OK

Roni

From: stephen botzko [mailto:[email-masked]] 
Sent: Friday, October 03, 2008 9:15 AM
To: Colin Perkins
Cc: Roni Even; Magnus Westerlund; IETF AVT WG
Subject: Re: [AVT] I-D Action:draft-ietf-avt-rtp-g719-02.txt

Colin,

I think the answer lies in the text describing CBR as a receiver capability.
Therefore I suggest it would be better to insert a "should not" in the CBR
parameter text indicating a device should not express the receiver
capability if it is capable of receiving a variable rate stream.  

 

The situation with congestion control is common to most speech codecs, whcih
tend to be fixed rate.  It seems inapproprate to make fixed rate encoding
out to be particularly evil, since that is generally the only mode of
operatoin that speech codecs have.  G.719 is actually much better for
congestion control, since it makes VBR reception a requirement except in the
rare cases where CBR is needed. 

Stephen Botzko

Roni,

So are you OK with

Cheers,
Colin

---

From: Colin Perkins <[email-masked]>
Date: Mon, 6 Oct 2008 22:54:47 +0100

Right - this is clearly a receiver capability, and that should be  
stated clearly. It also needs to be clear that it shouldn't be used,  
except in special circumstances, since the VBR mode is much safer  
from a network viewpoint.

Cheers,
Colin

On 3 Oct 2008, at 11:16, Roni Even wrote:
> Steve,
>
> I think that Colin wants this sentence in section 9 since this  
> codec has variable bit rate functionality and the CBR constrains  
> contradicts congestion. What it says is that if the codec support  
> VBT be careful when you ask for CBR.
>
> For section 9 it is not important if this is a receive capability,  
> the importance is the constrains for CBR. This is only relevant for  
> the parameter definition.
>
> Your text appears more precise, however how does the sender know it  
> is interacting with such a constrained devide?
>
>
>
> capability.  Therefore I suggest it would be better to insert a  
> "should not" in the CBR parameter text indicating a device should  
> not express the receiver capability if it is capable of receiving a  
> variable rate stream.
>
>
>
> Then delete the "implementations should not" sentence you suggest,  
> but leave the sentence about monitoring packet loss.
>
>
>
> Though perhaps even the last sentence on packet loss is redundant  
> (or over-specified), since surely packet loss monitoring and  
> congestion control is required for all connections, based on the  
> first paragraph in section 9?
>
>
>
> Or do you mean to put a more severe constraint on CBR than would be  
> applied to (for example)  FEC.  Since senders are not mandated to  
> use variable rate encoding (whether they signal CBR or not), I  
> think it is not a good idea to even hint that if you don't specify  
> CBR that you don't need to worry about congestion control.
>
>
>
> The situation with congestion control is common to most speech  
> codecs, whcih tend to be fixed rate.  It seems inapproprate to make  
> fixed rate encoding out to be particularly evil, since that is  
> generally the only mode of operatoin that speech codecs have.  G. 
> 719 is actually much better for congestion control, since it makes  
> VBR reception a requirement except in the rare cases where CBR is  
> needed.
>
>
>
> Stephen Botzko
>
> responses to congestion are severely limited, implementations  
> SHOULD NOT use the CBR parameter unless they are interacting with a  
> device that cannot support variable bit rate (e.g. a gateway to H. 
> 320 systems). When using CBR mode, a receiver MUST monitor the  
> packet loss rate to ensure congestion is not caused, following the  

-- 
Colin Perkins
http://csperkins.org/

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 07 Oct 2008 12:05:13 +0200

Colin Perkins skrev:
> Right - this is clearly a receiver capability, and that should be stated
> clearly. It also needs to be clear that it shouldn't be used, except in
> special circumstances, since the VBR mode is much safer from a network
> viewpoint.
> 

It is stated clearly in the offer/answer section. However, that do
contains one issue that I think we might need to clear up. The current
text is:

The parameter "CBR" is a receiver capability. For recvonly and sendrecv
streams, it indicates the desired constant bit rate that the receiver
wants to accept. A sender MUST be able to send constant bit rate stream
since it is a subset of the variable bit rate capability. If the offer
includes this parameter the answerer SHOULD send at the constant bit
rate if it is within the allowed session bit rate (b= parameter). The
Answerer MAY change the value of CBR to a lower rate but it is
RECOMMENDED to use the same rate. The answerer MAY add this parameter if
it wants to receive at a constant bit rate even if the offer did not
include the CBR parameter. In this case, the offerer SHALL send at the
constant bit rate but SHALL be able to accept media at variable bit rate.

The issue I see here is that if an offerer requires a particular CBR and
the answerer don't, it would actually be better if the answerer did not
include the CBR parameter in its response. Thus indicating its
capability to receive any rate in that direction. Thus I would propose
to change this to:

The parameter "CBR" is a receiver capability, i.e. only receivers that
really requires constant bit-rate should use it. For recvonly and
sendrecv streams, it indicates the desired constant bit rate that the
receiver wants to accept. A sender MUST be able to send constant bit
rate stream since it is a subset of the variable bit rate capability. If
the offer includes this parameter the answerer MUST send G.719 audio at
the constant bit rate if it is within the allowed session bit rate (b=
parameter). If the answerer can not support the stated CBR this payload
type must be refused in the answer. The answerer SHOULD only include
this parameter if it self requires to receive at a constant bit rate,
even if the offer did not include the CBR parameter. In this case, the
offerer SHALL send at the constant bit rate but SHALL be able to accept
media at variable bit rate. An answerer is RECOMMEND to use the same CBR
rate as in the offer, as symmetric usage is more likely to work. If both
sides requires a particular CBR rate there is the possibility of
communication failure when one or both sides can't transmit the
requested rate. In this case the agent detecting this issue will have to
perform a second round of offer/answer to try to find another working
configuration or end the established session. In case the offer
contained a CBR parameter but the answer does not, then the offerer is
free to transmit at any rate to the answerer, but the answerer is
restricted to the declared rate.

The above is more complete and deals more clearly with the both cases
when one side requires CBR. The case when both side requires CBR is not
fully covered as there are no mechanism to indicate what transmission
rates that are supported and thus allowing for negotiation of any
asymmetric capabilities around CBR. I do really hope we don't need that.

I also think we need to add some text in the declarative usage of SDP
about CBR. There we will be forced to use it in all directions that the
declarative SDP indicates. To me that is obvious but may need a
clarification. I would suggest this bullet in Section 7.2.2:

   The parameter "CBR" if included applies to all RTP streams using that
   payload type for which a particular CBR rate is declared.

Below is the resulting paragraph for the congestion control CBR discussion.

The CBR signalling parameter allows a receiver to lock down a RTP
payload type to use a single encoding rate. As this prevents the codec
rate from being lowered when congestion is experienced, the sender is
constrained to either change the packetization or abort the
transmission. Since these responses to congestion are severely limited,
implementations SHOULD NOT use the CBR parameter unless they are
interacting with a device that cannot support variable bit rate (e.g. a
gateway to H.320 systems). When using CBR mode, a receiver MUST monitor
the packet loss rate to ensure congestion is not caused, following the
guidelines in Section 2 of RFC 3551.

Comments?

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 07 Oct 2008 13:48:02 +0200

I missed one change to this proposed text and that was a reference to
section 9 for motivation:

Magnus Westerlund skrev:
> really requires constant bit-rate should use it. 

Usage of this parameter have negative impact on the possibility to
perform congestion control, see Section 9.

For recvonly and

The same thing is needed here:

> I would suggest this bullet in Section 7.2.2:
> 

Usage of this parameter have negative impact on the possibility to
perform congestion control, see Section 9.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 07 Oct 2008 13:48:25 +0200

Thanks,

The first issue is already covered in another email.

> which states that "any unspecified parameter MUST be ignored".

I have clarified this by changing both these statements:

An application implementing this payload format MUST understand all the
payload parameters specified in this specification. Any mapping of the
parameters to a signaling protocol MUST support all parameters. So an
implementation of this payload format in an application using SDP is
required to understand all the payload parameters in their SDP-mapped
form. This requirement ensures that an implementation always can decide
whether it is capable of communicating when the communicating enties
support this version of the specification.

Section 7.1:

Note, any unspecified parameter MUST be ignored by the receiver to
ensure that additional parameters can be added in any future revision of
this specification.

I hope that clarifies that the requirements are not contradicting, but
actually affects different part of the interoperability.

> - The requirements language should be part of section 2.

Ok

> modes..." - should this be "...the encoder decides between two..."?

Yes

> - Section 5.2.1, clarify that the bit rate is the codec bit rate, and

The sentence prior to the figure already talks about codec bit rate. I
have clarified that in the column heading and the in the following
sentence.

> unclear how the ToC is extended. Perhaps "ToC is immediately followed by"?

Fixed

> - Section 7.1: the description of the CBR parameter should reference

Yes, added: The usage of this parameter have implications on congestion
control that needs to be considered, see <xref target="sec-congestion"
></xref>.

> - Section 7.2, 2nd bullet point should reference the "channels" parameter.

Fixed

> should reference section 9.

Included in the proposal for changes of this bullet.

Cheers

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Tue, 7 Oct 2008 13:32:09 +0100

Hi Magnus,

These - and the changes in your other two messages - all look fine to  
me.

Cheers,
Colin

On 7 Oct 2008, at 12:48, Magnus Westerlund wrote:
>> 7.1,

-- 
Colin Perkins
http://csperkins.org/