Subject: [ippm] IPPM TCP draft-08

From: Alexander Zimmermann <[email-masked]>
Date: Tue, 07 Dec 2010 09:00:42 +0100

Copy of my review to ippm list

Alex

--

Hi Barry,

here are my comments...

* Sec 1, para 4:

   In this document, the
   maximum achievable TCP throughput is that amount of data per unit
   time that TCP transports when trying to reach Equilibrium, i.e.
   after the initial slow start and congestion avoidance phases.

IMO (see [1], [2]) TCP use SS tow reach Equilibrium and CA to "stay" in Equilibrium. IMO the statement
above is not correct. However, I'm not a Congestion Control geek, more a Lost Recovery expert.
Maybe (If you like, I you have time,...) you can ask Michael Welzl (IERTF ICCRG chair, author of [2]) for
a review, comment...

* Sec 1, para 5:

  A larger TCP CWND permits a higher throughput.

Hmm. If I have 1GB/s linespeed and an RTT of 2 ms, my BDP (CWND) is around 175 segments. On the
other hand if you have a 100Mb/s linespeed and an RTT of 25 ms, the BDP is around 219 segments.
Which connection is faster :-)

  TCP "slow start" and "congestion avoidance" algorithms
   together determine the TCP CWND size

Maybe better to say that the BDP of (path/network) determines the CWND, and with the help of SS and
CA you probe the path characteristic.
Take also a look at http://staff.psc.edu/jheffner/papers/senior_thesis.ps. I think we can get inspired
by John's text (esapecially section 2 and 3)

   In order to obtain the maximum throughput, it
   is critical to use optimal TCP Send and Receive Socket Buffer sizes
   as well as the optimal TCP Receive Window size.

The first part of the sentence is correct, the second part not. You CANNOT (directly) tune (eg
per sysctl) TCP Receive Window size. This is not under your control. Nagle and Clark have
some effects on this, and mainly the auto tuning algos (see [3], [4], [5], ([6])) tune your advertised
window. You set the buffer size via sysctl (tcp_rmem, tcp_wmem,) and maybe you can disable
auto tuning (tcp_moderate_rcvbuf=0), but (IMO) you cannot tune Receive Window.

So, IMO in the whole doc, I would prefer if you write "I/we set the receiver buffer socket size"

* Sec 2.1

   1 - The Slow Start phase, which occurs at the beginning of a TCP
   transmission or after a retransmission time out.

You are in SS if CWND is less the SSTHRESH. Starting with the transmission and RTO a only two
examples why this could happen. Restart after idle is another example. There are many reasons
why we could slow start. You examples are the common cases. A simple rewriting of the sentence
can fix this issue.

3 - The Retransmission Time-out phase => Loss Recovery phase

and delete the word "multiple", since in general Reno cannot recover multiple loss without an RTO
(see RFC3782)

* Sec 2.1, last para

  TCP test programs such as iperf, ttcp, etc. allow the sender to control
  the quantity of TCP Bytes transmitted and unacknowledged (in-flight),
  commonly referred to as the Send Socket Buffer.

I'm not a native speaker (as you can see :-)), but  what do you want to say here?
Maybe that the size of the send buffer limit the data in flight?

* Sec 3, para 8:

What is RED? :-) Add also add ref here 

* Sec 3, para 11:
   
  Linux OS kernel using TCP Reno

You can only choose NewReno under Linux (nevertheless the sysctl is named reno)

* Sec 3, para 13:

   A compliant TCP Throughput Test Device MUST allow adjusting both
   Send Socket Buffer and TCP Receive Window sizes.

The same as before... IMO "adjusting both Send and Receive Socket Buffer
size" is better. If you agree with me, grep for other sentences in the doc. There are many of them.

* Sec 3, para 14:

   - Measuring RTT and retransmissions per connection will generally
   require a dedicated communications test instrument

Or use our tool measurement tool flowgrind (http://freshmeat.net/projects/flowgrind)
Sorry for the advertisement ;-)

* Sec 3.2.1

If you use ping for the RTT calc, it is important to set the right packet size (-s) (if the network
is fast and have a low delay)

--

[1] Van Jacobson. “Congestion Avoidance and Control”. In: Proceedings of the ACM Symposium on
Communications Architectures and Protocols (SIGCOMM’88). ACM Press, 1988, pp. 314–329.
isbn: 0-89791-279-9. doi: 10. 1145/52324.52356.

[2] M. Welzl, M. Scharf, and B. Briscoe. Open Research Issues in Internet Congestion Control. Ed. by
D. Papadimitriou. Internet Draft. Sept. 2010.
url: http://tools.ietf.org/html/draft-irtf-iccrg-welzl-congestion-control-open-research-08.

[3] eduPERT. Automatic Tuning of TCP Buffers.
url: http://kb.pert.geant.net/PERTKB/TCPBufferAutoTuning.

[4] Pittsburgh Supercomputing Center. Enabling High Performance Data Transfers.
url: http://www.psc.edu/networking/projects/tcptune/.

[5] Mike Fisk and Wu chun Feng. “Dynamic Right-Sizing in TCP”. In: Proceedings of the 2nd Annual
Los Alamos Computer Science Institute Symposium (LACSI’01). 2001.

[6] Jeffrey Semke, Jamshid Mahdavi, and Matthew Mathis. “Automatic TCP Buffer Tuning”. In: SIGCOMM
Computer Communication Review 28.4 (Oct. 1998), pp. 315–323. issn: 0146-4833. doi: 10.1145/285243.285292.

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22222
// email: [email-masked]
// web: http://www.umic-mesh.net
//