[AVT] Re: Review draft-ietf-avt-avpf-ccm-07

[Magnus Westerlund <[e-mail]>]

Thanks for the review.

Even, Roni skrev:
> Hi
> It took me some time but I have some comments and nits
> 
> 1. In section 3.5.2 I suggest to delete "(as it is common in state-of-the-art video conferencing systems). I am not sure that it adds value and voice an opinion.

Agreed

> 
> 2. In 4.2.1.2 " If the media sender concludes that it can increase the maximum total media bit rate value, it SHALL wait before actually doing so, for a period long enough to allow a media receiver to respond to the TMMBN if it determines that its tuple belongs in the bounding set."
> 
> I was wondering if the SHALL is also true for unicast point to point case.
> 

Yes, this also applies to point to point. The reason is that one can't 
really reliably know which topology you are in. Thus, it is safest to do 
this also in point to point cases. Do you think we need to add any text 
on this?

> 3. In 4.2.2.2
> "As indicated in section 4.2.1.2, when a media sender determines
>    that an "owner" of a bounding tuple has left the session, then
>    that tuple is removed from the bounding set, and the media sender
>    SHALL send a TMMBN message indicating the remaining bounding
>    tuples.  If there are no remaining bounding tuples a TMMBN without
>    any FCI SHALL be sent to indicate this."
> 
> If there are no remaining bounding set what is the current bit rate. Does it mean that the sender may raise the bit rate to the negotiated rate in the signaling.

Yes, we have clarified this by adding the following sentence:

"Without a remaining bounding tuple, the maximum media bit rate and 
maximum packet rate negotiated in session signaling, if any, apply."

> 
> 
> 4. In 4.3.1.2
> 
> Do we need the note bellow in the final version.
> 
> "Note: Mandating a maximum delay for completing the sending of a decoder refresh point would be desirable from an application     viewpoint, but is problematic from a congestion control point of view.  "As soon as possible" as mentioned above appears to be a reasonable compromise"
> 

No, but this has been moved into Section 4.3.2.5 (Remarks) where it 
makes more sense to have it as explanation.

> 
> 5. in section 7.1 " MaxPacketRateValue = 1*15DIGIT" what are the units for this parameter. I think that based on the example it is in 1000's of bits per second but please clarify.
> Fix the value in example 3 based on the units, currently it say 120 and I assumed 120*1000 bits/s

We added clarification that this is packets per second.

> 
> 
> 6. In the 7.2 " The offerer MAY indicate the capability to support selected codec commands and indications.  The answerer MUST remove all ccm parameters which it does not understand or does not wish to use in this particular media session."
> I am not sure what you mean do not want to use, is it does not want to send or just does not want to receive but may send. 
> Based on your response the text for the answer in example 3 should have the same semantics.
>  
> 

The intention is that you must have the capability to receive such CCM 
requests and in cases, like TSTR to send the response. A agent is not 
required to initiate CCM messages, but expected I would say. Thus I 
propose the following addition to section 7.2:

Note, that including a CCM parameter in an offer or answer indicates 
that the agent (offerer or answerer) is at least capable of receiving 
the corresponding CCM message(s) and act upon them. In cases when the 
reception of a negotiated CCM messages mandates the agent to respond 
with another CCM message, it also must have that capability. Although 
not mandated to initiate CCM messages of any negotiated type it is 
generally expected that the agent will initiate CCM messages when suitable.


Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------

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