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

[Alexander Zimmermann <alexander.zimmermann at nets.rwth-aachen.de>]

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.

Am 11.11.2009 um 05:59 schrieb Matt Mathis:

> 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.

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.

> 
> 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.)

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.

> 
> The problem comes from setting cwnd to half the flight_size, even if
> the flight size was depressed for reasons unrelated to congestion
> 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
> 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.

Which variables/parameter do you have in mind?

> 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 <rs at netapp.com> wrote:
>> 
>> 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:mathis at DOMAIN.HIDDEN>
>>> 
>> *       Subject: [tcpm] Curiosity about draft-mathis-tcp-ratehalving
>> *       From: Carsten Wolff <carsten.wolff at rwth-aachen.de
>> <mailto:carsten.wolff at DOMAIN.HIDDEN> >
>> *       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
>> 
>> _______________________________________________
>> tcpm mailing list
>> tcpm at ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>> 
> _______________________________________________
> tcpm mailing list
> tcpm at ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

//
// 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: zimmermann at cs.rwth-aachen.de
// web: http://www.umic-mesh.net
//