Subject: [AVT] Comments on draft-ietf-avt-rtp-g729-scal-wb-ext-01

From: Magnus Westerlund <[email-masked]>
Date: Mon, 06 Feb 2006 12:02:00 +0100

Hi,

I have reviewed the G.729EV draft and have the following comments:

1. Section 3: The marker bit: I at least don't believe in marker bit 
definitions that depends on the profile. Please include the definition 
into the specification.

2. Section 4.2, MBS field:

This MBS field is an in-band signalling for performing congestion 
control. It does only work if one have two-way media traffic. Also the 
rules for raising the MBS limit or removing the limit at all are way 
underspecified for a real congestion control mechanism. Thus it does not 
remove the need for congestion control.

Is this MBS functionality defined in other transports for G.729EV? The 
reason I am asking is that the reason we included the CMR field in AMR 
(RFC 3267) was to support gateway cases and interworking with circuit 
switched.

Could you please provide some more motivation and reasoning for the 
purpose of this field.

3. Section 5.1: Maxptime:
Please define the parameter using a reference to SDP-New or at least RFC 
3267.

4. Section 5.1, Encoding consideration: At the end of the current 
sentence add: ", see section 4.8 of RFC 4288 []"

5. Section 5.1, You are allowed to split the author/change controller 
field an put yourself as an author and leave the current sentence only 
in the change controller field.

6. Section 5.3: I think there may need for some special multicast rules. 
  both maxbitrate and DTX are problematic in a multicast setting. The 
maxbitrate as it allowed to reduce the bit-rate lower than the session 
common. Which would force everyone to renegotiate. I don't think that is 
a good solution. The DTX is problematic as a session may or may not use 
it. Also here the first one not supporting it would trigger a 
renegotiation with everyone else. The question is what one wants here.

7. Section 5.1 and 5.3 MBS parameter: I do wonder a bit about the 
usefulness of this parameter. It provides a guidance, but do not remove 
the need for congestion control when starting to transmit.

8. Section 6, second paragraph:

"As this format transports encoded speech/audio, the main security
  issues include confidentiality and authentication of the speech/audio
  itself."

I would add "integrity" to the list of main security issues. 
Authentication provides the means of knowing that the packet really 
comes from whom it claims to come from. Integrity protects against 
changes of the data between the sender and receiver.

9. Congestion Control section is missing. You may very well use this 
text as start. Then please note the opportunities and limitations for 
performing congestion control.

    Congestion control for RTP SHALL be used in accordance with RFC 3550
    [RFC3550], and with any applicable RTP profile; e.g., RFC 3551
    [RFC3551].  An additional requirement if best-effort service is being
    used is: users of this payload format MUST monitor packet loss to
    ensure that the packet loss rate is within acceptable parameters.

The discussion around the above text is the question of what acceptable 
parameters are.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

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

---

From: "SOLLAUD Aurelien RD-TECH-LAN" <[email-masked]>
Date: Tue, 7 Feb 2006 12:31:25 +0100

Hi Magnus
Thank you for your review. My answers inline.

Regards
Aurelien 

> -----Message d'origine-----
> De : Magnus Westerlund [mailto:[email-masked]] 
> Envoyé : lundi 6 février 2006 12:02
> À : IETF AVT WG; SOLLAUD Aurelien RD-TECH-LAN
> Objet : Comments on draft-ietf-avt-rtp-g729-scal-wb-ext-01
> 
> Hi,
> 
> 1. Section 3: The marker bit: I at least don't believe in 
> marker bit definitions that depends on the profile. Please 
> include the definition into the specification.

OK, I will include the classical definition for audio, from RFC 3551 (M set to 1 at the beginning of a talkspurt)

> This MBS field is an in-band signalling for performing 
> congestion control. It does only work if one have two-way 
> media traffic. Also the rules for raising the MBS limit or 
> removing the limit at all are way underspecified for a real 
> congestion control mechanism. Thus it does not remove the 
> need for congestion control.
> 
> Is this MBS functionality defined in other transports for 
> G.729EV? The reason I am asking is that the reason we 
> included the CMR field in AMR (RFC 3267) was to support 
> gateway cases and interworking with circuit switched.
> 
> Could you please provide some more motivation and reasoning 
> for the purpose of this field.

No, MBS is not defined in other transports. The main target of G.729EV is VoIP with RTP.
The aim of MBS is to provide flexibility with regards to the bit rate scalability and embedded scheme.
A sender can decrease its sending rate at any time without previous notice, the receiver will understand and properly decode the packet. But we need something to request the other party to change its sending rate. It is close to the CMR functionnality. It is useful to have it inband to provide good reactivity.
This kind of "mode request" is present in lots of multi rate codecs like AMR, VMR, EVRC, ... (A more generic field is proposed in draft-wenger-avt-avpf-ccm-01 with TMMBR but it requires AVPF).

The motivation is to take advantage of the scalable/embedded property of G.729EV, mainly in scenarios involving multiple G.729EV converstations on the same device. For example on a Residential GateWay, you can plug several regular POTS phones or videophones. Depending on the global traffic, the RGW can dynamically adapt the bit rate of each conversation without external signaling.
If the simulateous number of calls increases, you can modify the bit rate of each call to maintain good quality within the available bandwidth.
It can be useful for large PSTN gateway also, if the traffic increases it can swith seamlessly to 8 kbps to maintain handling of new calls. 

> Please define the parameter using a reference to SDP-New or 
> at least RFC 3267.

OK. I did not put a reference because sdp-new is still under evaluation. I can put a reference to 3267 and update to new SDP reference when available.

> 
> 4. Section 5.1, Encoding consideration: At the end of the 
> current sentence add: ", see section 4.8 of RFC 4288 []"

OK

> 
> 5. Section 5.1, You are allowed to split the author/change 
> controller field an put yourself as an author and leave the 
> current sentence only in the change controller field.

OK, I'll split

>   both maxbitrate and DTX are problematic in a multicast 
> setting. The maxbitrate as it allowed to reduce the bit-rate 
> lower than the session common. Which would force everyone to 
> renegotiate. I don't think that is a good solution. The DTX 
> is problematic as a session may or may not use it. Also here 
> the first one not supporting it would trigger a renegotiation 
> with everyone else. The question is what one wants here.

Yes, all these options should be disabled for multicast, to avoid renegotiation.

Roni also suggested me to specify rules for sendonly and recvonly streams, not only bi-directionnal as it is implied now.

> 
> 7. Section 5.1 and 5.3 MBS parameter: I do wonder a bit about 
> the usefulness of this parameter. It provides a guidance, but 
> do not remove the need for congestion control when starting 
> to transmit.

It allows to know the receiving limit of the other party before receiving its first RTP packet with MBS. If there is no mbs parameter, how can you give this information? If it is not present, the sender may exceed the limit between the start of the call and the receiving of the first RTP packet. I agree it could be a short period of time...

> Authentication provides the means of knowing that the packet 
> really comes from whom it claims to come from. Integrity 
> protects against changes of the data between the sender and receiver.

OK

> 
> 
> 9. Congestion Control section is missing. You may very well 
> use this text as start. Then please note the opportunities 
> and limitations for performing congestion control.
> 
> The discussion around the above text is the question of what 
> acceptable parameters are.

OK. The scalable bit rate can be used to help congestion control.