Subject: [rmcat] review of draft-ietf-rmcat-cc-requirements-00

From: Zaheduzzaman Sarker <[email-masked]>
Date: Mon, 2 Dec 2013 16:22:36 +0100

Hi,

I was waiting for -01 version but decided to go against it. I think some 
of the points I mentioned here were already touched by other reviewers 
(now you know why I was waiting) but perhaps my version gives a 
different view.

My comments on draft-ietf-rmcat-cc-requirements-00 below-

In general this draft lists possible requirements and hints for 
evaluating congestion control algorithms. However, this draft ends up 
being a mix of general requirements and design specifications/choices. 
Sometime it only mentions a requirement as "deal well" and sometimes it 
goes sketching the solution (see below list for more specific comments). 
To me this needs to be avoided.

I still believe (I mentioned it in my first review of the earlier 
versions of the document a while back) proper explanations behind 
selecting the requirements could help reducing the confusion created by 
such mix specially for first time readers.

Comments on requirements:

Req 1: 1(a) "Should also deal well with" does not provide much 
requirements, does it? more clarification is needed to understand the 
issue and the requirements.

Req 2: Here it argues about self-fairness and being fair against TCP 
flows. Later in Req 11 it mentions more than self-fair and TCP. So I am 
a bit confused between these two requirements. I think it will be much 
better requirement if it is specified which are the competing flows we 
should be concerned about. I know the design team have come up with a 
list of competing flows which they think the evaluation should be done 
against. I would suggest to add that list here.

I also feel that as this document suggest quit a lot of possibilities it 
should define "what is fair" or at least say that "possible definition 
can be found in document XYZ (e.g. eval draft)".

Req 4: "Extra information could be added to the packets to provide more
         detailed information on actual send times (as opposed to
         sampling times), but should not be required". is this a 
requirement or guideline? It implicitly means the solution has to 
support both "sampling times" and "actual send time" even if it decides 
to operate on actual send time. if this is the case, cant we explicitly 
say that?

     4(a) I hope this is also valid for any future signaling schemes.

Req 5: I believe the solution space for backchannel can include more 
that just RTP header extension and I don't know about WG consensus that 
we only have to stick with RTP header extension as an alternative to 
RTCP, right? May be the requirement here really is that the alternatives 
to RTCP is allowed but they have to follow sub-bullet 5(b),5(c), 5(d) 
and 5(f) seriously and should show proper gain of not using RTCP 
according to AVPF/SAVPF profile.

Req 6: isn't this covered by sub-bullet 5(f) in Req 5? to me this is 
just a design choice to achieve 5(f).

Req 8: I am really thinking hard here on how to realize this as 
requirement. Looking at the current Internet I think the only way to 
achieve this is to allow increasing delay. The application (perhaps the 
"user of the application" is best to use here) may not like it and even 
decided to cut the session or it could allow such high delay for the 
time being. In plain English keep pumping data to the network until the 
user cuts the session. is this the requirement here?

Req 10: I will say the main requirement is fine and we don't need those 
sub-bullets to discuss solution scope (as Bill Ver Steeg said). Unless 
that is also an intention of this document.

Finally, I think three more things need to be discussed -
1) evaluation based on real codec and/or synthetic codec. In the last 
IETF88 ,meeting there were lots of discussions and opinions on that 
which boil down to the fact that we might need both of them. But I didnt 
see which requirement we were trying to address there from this 
document. Here I only see once stated "subjectively". I think our 
evaluation strategies should be driven from the requirement document 
where we need to ensure the requirements are fulfilled.
2) the interaction between user of RMCAT solution (applications) and the 
RMCAT solution. There is a deliverable from RMCAT WG on that topic. But 
there were no requirements on that. There were also some discussions 
about interaction between encoder and congestion control algorithm in 
the last IETF88 meeting. Shouldn't there be any requirements on the 
congestion control algorithm that it takes input from applications?
3) mentioning of circuit breaker, however I am not sure if that is a 
requirement to the application (user of RMCAT solution) or to the 
congestion control solution itself.

That is so far what I have.
-- 

Zahed

==================================================
ANM ZAHEDUZZAMAN SARKER

Ericsson AB
Multimedia Technologies
Laboratoriegränd 11
97128 Luleå, Sweden
Phone +46 10 717 37 43
Fax +46 920 996 21
SMS/MMS +46 76 115 37 43
[email-masked]
www.ericsson.com

==================================================

---

From: Randell Jesup <[email-masked]>
Date: Sat, 21 Dec 2013 04:01:17 -0500

On 12/2/2013 10:22 AM, Zaheduzzaman Sarker wrote:
> Hi,
>
> I was waiting for -01 version but decided to go against it. I think 
> some of the points I mentioned here were already touched by other 
> reviewers (now you know why I was waiting) but perhaps my version 
> gives a different view.
>
> Sometime it only mentions a requirement as "deal well" and sometimes 
> it goes sketching the solution (see below list for more specific 
> comments). To me this needs to be avoided.

Agreed it likely still goes too far in discussing the solution space, 
though it also must provide a framework for the WG to evaluate the 
relative fitness of solutions.  Hopefully the update will be better, 
though it likely will still need some more refinement.

> selecting the requirements could help reducing the confusion created 
> by such mix specially for first time readers.
>
>

reworded with a little more detail; removed "deal well with"

> flows. Later in Req 11 it mentions more than self-fair and TCP. So I 
> am a bit confused between these two requirements. I think it will be 
> much better requirement if it is specified which are the competing 
> flows we should be concerned about. I know the design team have come 
> up with a list of competing flows which they think the evaluation 
> should be done against. I would suggest to add that list here.
>
> I also feel that as this document suggest quit a lot of possibilities 
> it should define "what is fair" or at least say that "possible 
> definition can be found in document XYZ (e.g. eval draft)".

I limited the discussion of fairness even further here.  Per previous 
presentations to the WG, defining "what is fair" can lead to the heat 
death of the universe....  I'll note Michael Welzl has proposed 
something, but it's so general that I'm not sure it actually leads to 
any useful addition over the high-level comment here.

> support both "sampling times" and "actual send time" even if it 
> decides to operate on actual send time. if this is the case, cant we 
> explicitly say that?

This is saying that the algorithm can add data to outgoing packets to 
provide more reliable timestamping than is available from normal RTP 
timestamps.  (e.g. a header extension with higher-resolution and/or 
closer-to-actual-sending-time data).

> that just RTP header extension and I don't know about WG consensus 
> that we only have to stick with RTP header extension as an alternative 
> to RTCP, right? May be the requirement here really is that the 
> alternatives to RTCP is allowed but they have to follow sub-bullet 
> 5(b),5(c), 5(d) and 5(f) seriously and should show proper gain of not 
> using RTCP according to AVPF/SAVPF profile.

Modified to say "one alternative would be" to not rule out others (and 
some other edits from previous feedback).

> just a design choice to achieve 5(f).

Yes, mostly.  Removed (though people shouldn't forget that they can 
delay-and-piggyback feedback to some degree).

> achieve this is to allow increasing delay. The application (perhaps 
> the "user of the application" is best to use here) may not like it and 
> even decided to cut the session or it could allow such high delay for 
> the time being. In plain English keep pumping data to the network 
> until the user cuts the session. is this the requirement here?
>
>
> Req 10: I will say the main requirement is fine and we don't need 
> those sub-bullets to discuss solution scope (as Bill Ver Steeg said). 
> Unless that is also an intention of this document.

This is important enough I wanted to emphasize it to solution authors.  
Existing proposals have problems in this area.

> which boil down to the fact that we might need both of them. But I 
> didnt see which requirement we were trying to address there from this 
> 2) the interaction between user of RMCAT solution (applications) and 
> the RMCAT solution. There is a deliverable from RMCAT WG on that 
> topic. But there were no requirements on that. There were also some 
> discussions about interaction between encoder and congestion control 
> algorithm in the last IETF88 meeting. Shouldn't there be any 
> requirements on the congestion control algorithm that it takes input 
> from applications?

I have not addressed these yet.  I'm open to more detailed suggestions 
or discussion.

Thanks!

-- 
Randell Jesup -- rjesup a t mozilla d o t com