Subject: [tcpm] Increasing TCP's Initial Congestion

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 10 Nov 2010 19:27:29 -0000

Hi Jerry, Yaogong,

Reading your slides (i won't be online when you give your talk):

http://www.ietf.org/proceedings/79/slides/tcpm-0.pdf

| Is SACK required for IW10 to Perform?
| 
| * From the testbed at Google
|  - SACK does help reducing UCT but only by a small
|    percentage for both IW10 and IW3
| * 24 hours, 3-way parallel experiment at Google's
|   frontend servers
|  - IW10+NewReno still beats IW3+SACK
|
| Photos download Avg response time Retransmission rate
| IW10+SACK       2.6secs           4.1%
| IW10+NewReno    2.8secs           4.1%
| IW3+SACK        3.0secs           3.3%
| November 11, 2010     79th IETF, Beijing China      19

First, let me thank you for conducting these experiments with SACK and
NewReno. 

My comment at IETF78 was that Linux SACK (since 2.4.xx) can detect lost
retransmissions, and recover from them; 

On the 2nd slide you paraphrase this:

| How does IW10 perform
|  when SACK is either not available, or not adequately
|  implemented?

Did you disable this aspect of Linux SACK during your tests (to have a
RFC3517 compliant SACK sender)? Also, IIRC, Linux 2.6.2x already
implements draft-jarvinen-tcpm-sack-recovery-entry-02.txt // RFC3517bis.

I assume the fraction of lost retransmissions and early recovery entries
was small (afaik, Linux records these events individually). If these
counters were zero during your the testing, I'm fully satisfied.

I'm just worried that a good fraction of loss recovery was due to these
recent features (not widely available on other stacks), causing grief if
one simply tries to do IW10 without these other modifications.

Also, this comment on slide 13 indicates, that some flows had to do
RTO-based loss recovery, correct?

| * Under heavy load IW10 lost UCT advantage due to high PLR
| * IW10 UCT exhibits long tails 

Did you get traces off your testbed to investigate these long tail flows
further? One of the reasons might be the recent observation, that with
short flows, NewReno can sometimes recover more speedy than SACK (
http://www.ietf.org/mail-archive/web/tcpm/current/msg05875.html ).
(RecoveryPoint is close to the end-of-stream, and at least the last
segment prior to RP was lost).

The other reason could be, that SACK retransmissions are lost, but Linux
can not recover them any more. (RecoveryPoint is at the end-of-stream).

There might be additional cases causing RTO, though...

I would be very interested in looking at these long tail (high latency)
flow traces myself.

Richard Scheffenegger

---

From: Jerry Chu <[email-masked]>
Date: Wed, 10 Nov 2010 20:44:50 -0800

Hi Richard,

> retransmissions, and recover from them;

Understood. I haven't thought too deeply on this but on the surface I wonder how
critical will the efficient recovery of lost retransmissions be, or
it's mainly a
secondary concern?

> implements draft-jarvinen-tcpm-sack-recovery-entry-02.txt // RFC3517bis.

No I didn't get the time to study SACK details to run the tests. Both Yuchung
and I simply disabled SACK altogether (sysctl_tcp_sack = 0).

> one simply tries to do IW10 without these other modifications.

Understood. Unfortunately I didn't get the time to study the case you
brought up in details. The tests so far were more to address Matt's
concern about SACK (or lack of) in general for IW10.

> RTO-based loss recovery, correct?

I think so but I don't have the numbers with me, nor are they on the web
page. We used to collect netstat -s output but we discovered the former
wasn't valid anymore when we switched to slow link tests - normal
background traffic become significant portion of "netstat -s" compared
to 64Kbps rate to obscure the numbers.

> http://www.ietf.org/mail-archive/web/tcpm/current/msg05875.html ).

Yes I do see this but wasn't sure if it's due to the large variation of numbers
for 64Kbps links (and it could still be the case).

> I would be very interested in looking at these long tail (high latency)

Ok, will arrange to send you the trace dumps.

Thanks,

Jerry