Subject: Re: [tcpm] Curiosity about draft-mathis-tcp-ratehalving

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 10 Nov 2009 00:09:02 -0000

Hello Carsten,

This is a very good question indeed.

Keeping the ACK clock running, and avoiding bursts of segments delivered
all at once in a single burst to a L2 LAN network is something
where my interests are too... (as todays hosts are increasingly capable
of oversaturating slightly dated network equipment with full wire speed
traffic).

Is there a procedure to revive / adopt a dead draft?

I have not spent much time on this issue, but noted the burst behavior
After fastretransmit.

As RateHalving extended the scope of Limited Transmit (with the similar
goal), shouldn't this be discussed for inclusion in a RFC 3042bis?

Since certain other congestion algorithms have a beta of less than 0.5 
(ie. BIC, CUBIC use 0.8) when selecting a new ssthresh, perhaps the
effect
of RateHalfing, but with 2 out of 3 (0.66) policy or 3 out of 4 (0.75)
at the end of the RTT should be investigated? (To be less conservative
When reducing the sending rate).

One extension to the draft might be the discussion on how to deal with
RFC 3465 (ABC) during rate halving; with SACK, ABC could still be
employed,
And a new segment triggered only, when 2*MSS has been covered by the new
SACKs...

Regards,

Richard Scheffenegger
Field Escalation Engineer
NetApp Global Support 
NetApp
+43 1 3676811 3146 Office (2143 3146 - internal)
+43 676 654 3146 Mobile
www.netapp.com <BLOCKED::http://www.netapp.com/>  
Franz-Klein-Gasse 5
1190 Wien 

*	To: Matt Mathis <mathis at psc.edu <mailto:[email-masked]>
*	Subject: [tcpm] Curiosity about draft-mathis-tcp-ratehalving
*	From: Carsten Wolff <carsten.wolff at rwth-aachen.de
<mailto:[email-masked]> >
*	Date: Wed, 4 Nov 2009 13:48:51 +0100
  _____  

Hello Matt, everyone,

I'm curious about draft-mathis-tcp-ratehalving 
(http://tools.ietf.org/id/draft-mathis-tcp-ratehalving-00.txt) and why
it 
never exceeded version 00 and expired years ago. It seems, several of
the 
ideas (fack, ratehalving, the concept of rhcwnd) in this paper made it
into 
the Linux TCP implementation in some form, which means they're part of a
big 
chunk of today's web servers and other Internet hosts. Why has there
been no 
interest in taking this draft further?

Cheers,
Carsten

---

From: Matt Mathis <[email-masked]>
Date: Tue, 10 Nov 2009 23:59:03 -0500

We abandoned Rate-Halving because we encountered a problem that we
were not able to overcome at the time. It performs very poorly when
you have bursty applications. Unfortunately the very feature which
causes this problem came to be mandated by 2581 and is now entrenched
in 10 years of other congestion control standards.

This is part of the reason that with large multi core systems, it is
hard to get a single TCP stream to run at really high speeds when
there is much load on the CPUs. Todays TCP implementations all suffer
badly if the sender frequently stalls due to running out of data, even
for fractional RTTs (e.g, waiting for the scheduler or a disk seek.)

The problem comes from setting cwnd to half the flight_size, even if
the flight size was depressed for reasons unrelated to congestion
control. This and other algorithms (e.g. some of the burst suppression
stuff) couple fine grained (less then 1 RTT) events to congestion
control where they potentially have impact lasting for thousands of
RTTs. As far as I am concerned this is wrong and has always been
wrong.

This coupling is an intrinsic property of rate halving. At the time
the draft stalled we were looking for a way to gracefully prevent the
new cwnd from going below old_cwnd/2, without upsetting people if
flight_size was already below cwnd/2 (This condition implies no window
adjustment during recovery).

Now more than 10 years later I think I understand the right answer.
TCP congestion control needs to be reparameterized, with different
control variables. This would require ripping out and replacing most
of the current congestion control code. All of the old problems still
need to be solved, but under the new parameterization the algorithms
would become much simpler and probably better behaved.  This is a lot
more effort than a simple update of rate-halving or some other
document.   The Relentless/TCP-unfriendly stuff touches on it, however
they are really orthogonal problems.

Feel free to re-open the rate-halving draft.  There is no formal
process: take the existing document and edit it.  You might check to
see if there were any changes posted to
http://www.psc.edu/networking/ftp/papers/draft-ratehalving.txt that
don't appear in the last IETF draft.   If the other original authors
(cc'd above) don't choose to participate, their effort should be
mentioned in the acknowledgement section.  I would like to be included
as an author, however I can only invest extremely limited time and
energy.

If you do reopen the document, I would like it to include some version
of the above discussion.

Thanks,
--MM--
-------------------------------------------
Matt Mathis      http://staff.psc.edu/mathis
Work:412.268.3319   Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.

On Mon, Nov 9, 2009 at 7:09 PM, Scheffenegger, Richard <[email-masked]> wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Alexander Zimmermann <[email-masked]>
Date: Wed, 11 Nov 2009 14:13:13 +0100

Hi Matt,

thanks for the quick answer. Carsten and I stumbled upon rate halving during 
our investigation how Linux TCP handles segment reordering. Since we currently 
don't want to skip our primary goal, I want to figure out if we could/should 
reanimate the ID with respect to men power, etc.

> in 10 years of other congestion control standards.

Ok, I see. However, but why is it not possible to do a step by step approach. 
Rate halving reduces TCP burstyness during recovery and IMHO it is a valuable 
feature, more straight forward then artificially inflating/deflating. Fixing 
the poor TCP performance in case of bursty applications can be seen as another 
step.

> for fractional RTTs (e.g, waiting for the scheduler or a disk seek.)

Is this different on a single core? I mean if my TCP doesn't get enough
CPU time on my single core, I cannot send with high speed, too.

> control.

Ok, but what can we do? As RFC 2861 describes, we can only know
about the current BDP if we are not application (or similarly)
limited. Do you want do move away from AIMD?

> This and other algorithms (e.g. some of the burst suppression
> control variables.

Which variables/parameter do you have in mind?

> This would require ripping out and replacing most

//
// 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-22220
// email: [email-masked]
// web: http://www.umic-mesh.net
//