Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard

From: Sally Floyd <[email-masked]>
Date: Wed, 14 May 2003 16:08:34 -0700

Armando -

>The other method is to apply a
>limit (maxburst) on "the number of data packets that can be sent in
>response to a single acknowledgement".  Why not combine the two (as done
>in the SCTP implementer's guide) into a simple algorithm as follows?
>
>if((flightsize + Max.Burst*SMSS) < cwnd)
>         cwnd = flightsize + Max.Burst*SMSS

Well, since you asked...

I happen to think that the algorithm above, of reducing the congestion
window as a method to limit transient bursts that would last a
fraction of a round-trip time, is fatally flawed and should NEVER
be used by a transport protocol.

I am several months overdue to write a note to the Linux gang about this
(it seems that the TCP implementation in Linux does this also),
but here is the jist of it, if I did manage to get to it:

(This note from some February 11 email of mine that was part of a
conversation about this with Tom Kelly, Brian Tierney, and Matt
Mathis.  The email conversation was started because some cases of
terrible performance of Linux TCP with HighSpeed TCP were tracked
down to exactly this code, as I recall...)

>To: Tom Kelly <[email-masked]>, Brian Tierney <[email-masked]>
>cc: Matt Mathis <[email-masked]>
>Bcc: 
>From: Sally Floyd <[email-masked]>
>Subject: OtherReductionsCM
>Date: Tue, 11 Feb 2003 15:32:12 -0800
>Sender: [email-masked]
>
>Brian and Tom -
>
>Here are my arguments why the code for OtherReductionsCM,
>in tcp_moderate_cwnd(), should be removed from the Linux code base:
>
>* If there is reordering in the forward or reverse path, and an ack
>arrives acknowledging more than three packets, then cwnd will be
>reduced.  This is not a robust response to reordering.  The goal
>is to make TCP more robust to reordering, not less robust.
>
>* If there are losses on the reverse path, and an ack arrives
>acknowledging more than three packets, then cwnd will be reduced.
>I think that congestion control for the reverse-path traffic would
>be a good thing.  However, I don't think this would be a good way
>to achieve it.
>
>* It is common for ACKs to be "compressed" in the network, by
>piling up in a queue.  Assume that the receiver uses delayed acks,
>so that each ack acknowledges two packets.  If N such acks arrive
>at the TCP sender back-to-back, for N > 1, and the host decides
>to process two ack packets before invoking the TCP send routine
>to send new packets, then when the host processes the second ACK,
>tcp_moderate_cwnd() will result in the congestion window being
>reduced.  Thus, the only way to avoid OtherReductionsCM being
>invoked would be for the TCP sender to fully process each ACK,
>including sending new packets triggered by that ACK, before
>processing subsequent ACKs.  This doesn't leave the implementation
>much flexibility.
>
>* After the sender retransmits a lost packet, the receiver is likely
>to send an ACK acknowledging N packets, for N>3.  When the sender
>receives this ACK, then is it going to *again* reduce its congestion
>window, from OtherReductionsCM?  If so, this seems rather perverse to
>me.
>
>* If the receiver for some unknown reason sends an acknowledgement
>acknowledging more than 3 packets (and some receivers in fact don't
>send an ack for every two packets, even though they should),
>then the TCP sender will respond by reducing cwnd.  Not too robust.
>
>* I imagine that there are other cases as well where 
>OtherReductionsCM will do undesirable things...
>
>And here is the caveat:
>
>I have only looked at the code on Brian's viewgraph, not in the Linux
>source code, so I *could* be missing some critical piece of
>information...
>
>- Sally

- Sally
http://www.icir.org/floyd/
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Thu, 15 May 2003 20:07:40 -0500

Sally:

I have thought a bit on this and have worked
out where things fall apart in the face of
reordering.. but this leads me to ask a question..

Lets assume we do have drastic reordering that
is effecting the network..  say something like

-----10 segments outstanding---->
  and of course the reciver sends 5 acks (every
other segment)... but worse case happens and
you get

<----ack5
<----ack4
<----ack3
<----ack2
<----ack1

Now the first ack that arrives acknowledges all
of the 10 segments.. the next 4 are considered
old and dropped...

Using ABC we would advance our cwnd from 10
to 11.

But if you apply the max burst you drop to 4.. real
bummer :-<

However what happens to the network now without
some sort of burst limit? The sender is now suddenly
able to spike out 11 segments of data.  And I know
this can't be a good thing :<

 From some testing I was doing on my local lan with some
networks.. series of bursts like this surely caused
drops in the routers.. I can even provide you with
ethereal traces showing this... the packets would
hit the wire in a burst of say 10 or so packets and by
the second or third burst like that .. you would still see
the packets on the wire.. but they would never get into
the outgoing side of the router.. being dropped by the
line cards... note these are not cheap routers aka they
are not your standard home office stuff.... (I won't
say whos they were but you can probably guess :>)

Anyway.. my point is.. all hardware.. no matter how
expensive has some constraints as to how much
burstyness it can handle... thus if you don't cut down
how many you can burst out at once you are going to
hit a loss event and that will effect your performance more I
think :<

Maybe there is someway we can control the sending without
killing the cwnd.. but then as Mark Allman as stated.. you get
two control variables and that seems like it might lead to
interaction and trouble???

???? any thoughts on this???

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)