Subject: [AVT] Comments on draft-ietf-avt-tfrc-profile-05

From: Magnus Westerlund <[email-masked]>
Date: Mon, 07 Nov 2005 06:36:25 +0100

Hi Ladan,

I have reviewed the draft and have some comments:

1. Section 2. A benefit for DCCP is also its possibilities to negotiate 
future defined congestion control mechanisms.

2. Section 4. RTP data header extension: I think both of the SHOULDs in 
this paragraph needs to be MUST. Yes, I am arguing that AVP has to 
relaxed wording in regards to header extensions.

3. Section 4. RTP data header extension: Is the first 16 bits field 
values shared with the AVP profile or is this a new scope?

4. Section 4. RTCP report interval: "This profile is restricted to 
unicast flows, therefore at all times there is only one active sender 
      and one receiver." This formulation is a bit unclear. As there may 
only be unicast traffic but that doesn't present there from being 
multiple sources (SSRC).

5. Section 4. Encapsulation: Should this profile be defined for use over 
UDP-Lite?

6. Section 5.2, first bullet: I would like to add the word 
"transmission" before timestamp to clarify what timestamp is indicated 
here as the packet will contain multiple ones.

7. Section 7. Also for (t_i) should it be indicated that it is the 
transmission timestamp that is referred to.

8. This draft is still not declaring the possibility to use AVPF RTCP 
feedback messages.

9. Something that maybe should be clarified is if any congestion control 
actually occur of the return path. What will feedback message packet 
losses mean for the forward link and will that induce any reduction in 
the feedback traffic. In TCP losses of ACK will implicitly mean a 
reduction of the forward traffic which in its turn reduces the ACK path. 
However it is not obvious that TFRC will result in this. Which makes me 
question if some criteria for the handling of the feedback path is needed.

10. Figure 3, the bit-pattern numbering is misaligned.

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: Colin Perkins <[email-masked]>
Date: Fri, 11 Nov 2005 08:22:12 -0800

On 6 Nov 2005, at 21:36, Magnus Westerlund wrote:
> 1. Section 2. A benefit for DCCP is also its possibilities to  
> negotiate future defined congestion control mechanisms.
>
> 2. Section 4. RTP data header extension: I think both of the  
> SHOULDs in this paragraph needs to be MUST. Yes, I am arguing that  
> AVP has to relaxed wording in regards to header extensions.
>
> unicast flows, therefore at all times there is only one active  
> sender      and one receiver." This formulation is a bit unclear.  
> As there may only be unicast traffic but that doesn't present there  
> from being multiple sources (SSRC).
>
> 5. Section 4. Encapsulation: Should this profile be defined for use  
> over UDP-Lite?

I'm not sure we have a good understanding of how TFRC should respond  
to corruption based loss?

> "transmission" before timestamp to clarify what timestamp is  
> indicated here as the packet will contain multiple ones.
>
> 8. This draft is still not declaring the possibility to use AVPF  
> RTCP feedback messages.
>
> 9. Something that maybe should be clarified is if any congestion  
> control actually occur of the return path. What will feedback  
> message packet losses mean for the forward link and will that  
> induce any reduction in the feedback traffic. In TCP losses of ACK  
> will implicitly mean a reduction of the forward traffic which in  
> its turn reduces the ACK path. However it is not obvious that TFRC  
> will result in this. Which makes me question if some criteria for  
> the handling of the feedback path is needed.

We should probably just follow RFC 3448 here; clarifying that if needed.

Cheers,
Colin