Subject: [ledbat] Review of draft-ietf-ledbat-survey-01

From: Mirja Kühlewind <[email-masked]>
Date: Sun, 17 Oct 2010 18:42:18 +0200

Hi,

before giving a detailed review I would like to give you a short overview what 
I was generally expecting to be the content of this doc before reading it. I 
was hoping to get the following question answered:

1. Which protocols do exist and how do they work? 
	I would suggest to mention all protocols by name. Sometimes you just put the 
reference, which makes it harder to follow the text. Maybe even have a 
separate subsection for each protocol. That helps to achieve a faster 
overview. 
	About the description how a protocol works I wasn't always able 
to understand your all explanations without looking up the original paper. 
Sometimes it was more written like a related work section, which is not 
intended to be completely understandable but gives the right pointers if 
something sounds intresting. I think this doc should be understandable 
without looking up the references. (see later detailed comments as well)

2. What are the advantages and disadvantages of a protocol? 
	This is only discussed completely for some of the protocol so far. I would 
except this to be more explicit for every described protocol.

3. How do the protocols differ from each other?
	Would be nice to have a paragraph at the beginning or the end that goes 
quickly through all the described protocols and explains the differences or 
the one specific feature about a protocol compared to others.

I don't know if those questions go in-line with what your goals are in this 
doc. But if yes, I think they are not fully addressed yet.

Here the more detailed comments:

1. Introduction:
-------------------
I don't understand your classification. What does 'non-delay-based' 
and 'orthogonal' actually mean? I guess the delay-based ones are mainly 
scavenger protocol which means they are not only lower than best effort but 
moreover try to be non-intrusive. Whereas the non-delay-based one just try to 
be less aggressive than TCP.
I'm also not sure if 'application layer approaches' is the right term. Some of 
the approaches are actually implemented in Linux and not in 
application layer...? But all of them assume to have some application 
knowledge, i guess (as well as some of the approaches mention in section 
5 'orthogonal work'). 'Orthogonal work' mostly refers to approaches with 
network-support...?

2. Delay-based transport protocol
-------------------
1. paragraph: 
  - the connection to delay is missing
  - maybe give an overview which protocols will be discussed first and then 
have differnet subsections for the protocols

3. paragraph:
"The congestion avoidance behavior is the protocol's most important
   feature in terms of historical relevance as well as relevance in the
   context of this document (it has been shown that other elements of
   the protocol can sometimes play a greater role for its overall
   behavior [Hen+00])."
Congestion Avoidance is not explained/introduced. But why is this information 
need here?

- The explanation of TCP Veags seems quite complicated. Maybe give first an 
overview in one sentence like: " TCP Vegas linearly increases or decreases 
the rate based on the difference of estimated throughput and actual 
troughput. The estimation is based on RTT measurements."

- I would say to write "linear increase" is not enough. I would explicitly 
write "linear increase by one segment per RTT"

- Disadvantages of TCP Vegas should be discussed here as well.

4. paragraph:
   I looked at the reference Bra+94. I could only find one reference to 
another delay-based protocol. Maybe I looked wrong but please check. But I 
would anyway prefer to have protocol names instead of a (random) reference.  
And maybe move this whole paragraph to the beginning of this section. The 
structure of this section is quite hard to follow.

5. paragraph: 
   - Move to beginning of section? Otherwise the link to non-intrusive 
protocol in general is missing.
   - I would introduce the protocol with the full name -> TCP Low Priority 
(TCP-LP)
   - What does "...due to the non-linear relationship between throughput and 
RTT mean". This is quite hard to understand without reading the reference. I 
would prefer to have those things more explained instead of just giving the 
reference.
    - "... have a larger RTT than standard TCP flows". I though the problem is 
if they have a smaller RTT. Please explain.

6. paragraph (TCP-Nice):
   - What is "... a fixed predefined fraction of delay-based incipient 
congestion signals"? Please give more details.
   - "One more feature of TCP-Nice is the ability to support a congestion 
window of less than one packt..." It this a specific feature of TCP-Nice or 
could every other protocol do this as well. If so I would phrase that 
differently e.g. "Furthermore, TCP-Nice introduced a way to..."
   - "the authors of [Ven+02] show that TCP Nice achieves its goal of 
efficiently utilizing spare capacity..." What does efficiently mean?

7. paragraph (TCP-LP):
   s/TCP-LP uses only the one-way delay/TCP-LP uses only the variation of 
one-way delay/

8. paragraph:
   What does "maintaining the window size" mean?

9. paragraph:
   What does "largely non-intrusive" mean? I know, it is hard to give a short 
overview of a protocol without going to much into detail but still keep the 
important bits. But I'm afraid these vague information doesn't help the 
reader a lot.

10. paragraph (Sync-TCP):
   - I looked a the paper and I don't see what you mean by "Sync-TCP adapts 
the parameters...". What they do is, they try to synchronize all flow to do 
the same thing at the same time by using a parametrization which needs to be 
the same for all flow globally. I think that's a very bad idea. And this 
should be explained here. Furthermore, they actually wait a while until they 
react to congestion to be sure that every other flow got the signal as well. 
Not sure about this idea neither. Please explain Sync-TCP more detailed and 
discuss advantages and disadvantages.

11. paragraph:
    Please mention the names of the protocol instead of just giving the 
reference that makes it easier to follow.

2.1. Accuracy of delay-based congestion predictors
--------------------
- Are those points given in a specific order? I think the most import one 
should come first.
- I looked up Fig 2 in McC+08. I don't see the point and Fig. 2 didn't even 
seemed to be explained... please check.
- Another point is, that the minmum delay you measure is usually not the 
actual base delay if there is permanently traffic on the link. Thus different 
flows might operate with different values for the base delay.
- But I'm not sure if this whole section belongs into this doc. Some of the 
points are discussed in the LEDBAT protocol spec.

2.2. Delay-based congestion control = LBE?
--------------------
- I think these are the more important points. Maybe merge the previous 
section with this one. I would prefer a different title for this section...

3. Non-delay-based transport protocol
---------------------
- There should be some introduction what this section is about/ what the 
common thing of the protocols explained here is. 
- 2. paragraph: Only the case where the weight is smaller than 1 actually 
belong here. Maybe take the 3. paragraph first.
- A general discussion what is good or bad about these approaches is missing.

4. Application layer approaches
--------------------
- Again, give an overview first.

- "A simplistic, application-level approach to a background transport
   service may just consist in scheduling automated transfers at times
   when the network is lightly loaded, as described in e.g.  [Dyk+02]."
   This sentence sounds wired to me, maybe s/consist in scheduling/be to 
schedule/

- Why don't you say that this approach is about 'cooperative proxy caching'? 
That would make it much easier to understand for me.

- In the 2. paragraphyou talk about a "Linux implemenation". I guess that is 
not really application layer anymore than...? As mention before, I don't 
really see your classification.

- 3. paragraph:
"A similar method..." I don't see the similarity except that there are both 
receiver-based. I would e.g. take 'having receiver involvement' for 
classification.

5. paragraph:
Is this approach is really non-intrusive? I guess you disturb a TCP flow as 
long as your rate is not zero and you probably can disturb a lot if your 
minimun rate is too high for a given bottleneck.

6. paragraph:
This is only done on your own interface to not distrub other flows from the 
same system right? Its nothing about TCP flows from other systems, right? 
Please make this clear.

- Are all this approaches actually belonging in this doc? Maybe don't discuss 
in such a detail or if your think they are important please discuss use cases 
and advantages/disadvantages. Or maybe just change the structure to make the 
link to Lower-than-Best-Effort Transport Protocols more clear. I don't 
know...

5. Orthogonal work
--------------------
- I guess the right classification would be 'with network support'...?

- NF-TCP is also delay-based. Not sure where this protocol belongs in your 
classification, but it seems to be added later on to this place.

- Please discuss pros and cons

Maybe add a summary at the end to show the most important features/difference 
of the discussed approaches. This would help to get a better overall view of 
this area.

Hope my comments help. 

Mirja