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

[Matt Mathis <mathis at psc.edu>]

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