Subject: Re: [tcpm] Interest indraft-mathis-tcpm-proportional-rate-reduction-00?

From: "SCHARF, Michael" <[email-masked]>
Date: Fri, 1 Apr 2011 09:07:17 +0200

Matt,

> When you said "interest", did you actually mean as a WG item?   You
> didn't quite ask the question.
>
> We plan to update the document and bring it to the next IETF in any
> case, and we know of  a number of individuals who have expressed
> interest.

It would be excellent to have an update that addresses the comments on the list.

> My only reservation with making it a WG item is that we expect to
> broaden the scope somewhat, and the current file and document names
> may not be appropriate.   As long as a future scope changes are not a
> problem, a WG item would be preferred.

Could you please detail these expected scope changes?

Thanks

Michael

---

From: Matt Mathis <[email-masked]>
Date: Sat, 2 Apr 2011 23:35:07 -0400

We will address comments raised on the list.   So far most have been
clarifications, but people have found a minor bug or two.

The scope change has to do with the issue that Nandita mentioned earlier in
the thread: linux reduces cwnd to flightsize beyond the extent required by
standards.  There are a number of people who insist that this algorithm
(cwnd moderation) is critical for correct operation.   We want to consider
an alternative or two and evaluate the trade-offs.   The resulting document
is likely to have wider scope than just recovery, but we haven't determined
exactly yet.   (An no, it isn't a Linux specific issue).

The point of view will be: increasing the accuracy with which the primary
congestion control algorithm regulates the TCP window, by reducing the
extent to which non-loss/non-ecn events such as application stalls,
reordering etc, perturb cwnd.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

---

From: Yuchung Cheng <[email-masked]>
Date: Fri, 8 Apr 2011 11:13:42 -0700

Hi folks,

As promised, we have came up a few examples to best illustrate the
difference among PRR-RB, RFC3517, Linux. Linux currently implements some
variant of rate-halving.

The tables below some example the per ACK response during the first
round-trip in Fast-recovery of Linux, RFC3517, and PRR-RB. In all examples,
cwnd = pipe = 20 when the first packet is lost.

Each column in the table shows the internal stats upon receiving an
(dup)ACK with appropriate SACK blocks

ack#: the ack of a packet. X means the packet is dropped.cwnd: cwnd
      after processing the ACK. It is not shown in PRR-RB because cwnd
      does not control the numbre of packets sent during Fast-Recovery.

pipe: estimated packets in the network

sent: packets sent. N: new data. R: retransmits

RB:   PRR-RB uses the reduction bound for
      sndcnt = min(ssthresh - pipe, prr_delivered - prr_out)
      s: the first term. f: the second term

NOTE: we use the 3517 loss marking in all algorithms. (Linux default uses
the more aggressive FACK). Therefore all Fast-Recovery starts after ACK3.

-------------------------------------------------------------------------------
1. First packet is lost. Trail new data beyond RecoverPoint

ack#   X  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19
LINUX
cwnd:    20 20 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11
pipe:    19 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10
sent:     N  N  R     N     N     N     N     N     N     N     N

3517
cwnd:    20 20 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11
pipe:    19 19 18 18 17 16 15 14 13 12 11 10 10 10 10 10 10 10 10
sent:     N  N  R                          N  N  N  N  N  N  N  N

PRR-RB
pipe:    19 19 18 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 10
sent:     N  N  R  N     N     N     N     N     N     N        N
RB:                                                          s  s

All algoritms send same amount. 3517 experiences the “half-window” of
silence

-------------------------------------------------------------------------------
2. First packet is lost. No new data beyond RecoveryPoint

ack#   X  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19
LINUX
cwnd:    20 20 17 16 16 15 14 13 12 11 10  9  8  7  6  5  4  3  2
pipe:    19 18 16 16 15 14 13 12 11 10  9  8  7  6  5  4  3  2  1
sent:           R

3517
cwnd:    20 20 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
pipe:    19 18 16 16 15 14 13 12 11 10  9  8  7  6  5  4  3  2  1
sent:           R

PRR-RB
pipe:    19 18 16 16 15 14 13 12 11 10  9  8  7  6  5  4  3  2  1
sent:           R
RB:                                  s  s  s  s  s  s  s  s  s  s

Linux cwnd drops to 2 and does slow-start after recovery. This applies
to ANY cwnd value.

-------------------------------------------------------------------------------
3. First 15 packets are lost. Trail data beyond RecoveryPoint

ack#   X  X  X  X  X  X  X  X  X  X  X  X  X  X  X 15 16 17 18 19
LINUX
cwnd:                                              20 20  5  5  5
pipe:                                              19 19  4  4  4
sent:                                               N  N  R  R  R

3517
cwnd:                                              20 20 11 11 11
pipe:                                              19 19  4 10 10
sent:                                               N  N 7R  R  R

PRR-RB
pipe:                                              19 19  4  6  6
sent:                                               N  N 3R  R  R
RB:                                                       f  f  f

a) 3517 sends a larger burst (7 retransmits) under heavy drops compared to
   Linux and PRR-RB
b) Linux cwnd drops to 5 and does slow-start after recovery

-------------------------------------------------------------------------------
4. First 15 packets are lost. No new data beyond RecoveryPoint

ack#   X  X  X  X  X  X  X  X  X  X  X  X  X  X  X 15 16 17 18 19
LINUX
cwnd:                                              20 20  3  3  3
pipe:                                              19 18  2  2  2
sent:                                                     R  R  R

3517
cwnd:                                              20 20 10 10 10
pipe:                                              19 18  2  9  9
sent:                                                    8R  R  R

PRR-RB
pipe:                                              19 18  2  4  4
sent:                                                    3R  R  R
RB:                                                       f  f  f

a) Linux cwnd drops to 3 and does slow-start after recovery
b) The second term in the reduction-bound in PRR-RB lowers the burst size
   (on ack 17). We are developing on a new algorithm to send as many as
RFC3517
   but pace out the 10 packets.

-------------------------------------------------------------------------------
5. First 2 and last 8 packets are lost. No trailing data beyond RecoverPoint

ack#   X  X  2  3  4  5  6  7  8  9 10  X  X  X  X  X  X  X  X  X
LINUX
cwnd:       20 20 16 15 15 14 14 13 12
pipe:       19 18 15 15 14 14 13 12 11
sent:              R     R

3517
cwnd:       20 20 10 10 10 10 10 10 10
pipe:       19 18 15 15 14 13 12 11 10
sent:              R

PRR-RB
pipe:       19 18 15 16 15 14 13 12 11
sent:             2R
RB:                         s  s  s  s

a) 3517 will timeout if the only retransmit is lost again