Re: [tcpm] RFC3465:TCP ABC and SACK'ed data

[Erik Hugne <[e-mail]>]

Here's from a test just this morning, wgetting a 10MB file.
https://www.dropbox.com/sh/86u3nzcwukjzpzv/AAAlp_Me7wXf7PRyuWFq9Lmwa

//E

On Fri, May 23, 2014 at 04:06:12PM -0700, Yoshifumi Nishida wrote:
> This is just out of my curiosity, but can we share the tcpdump file for
> this?
> --
> Yoshi
> 
> On Friday, May 23, 2014, Erik Hugne
> <[e-mail]<javascript:_e(%7B%7D,'cvml','[e-mail]');>>
> wrote:
> 
> > Maybe..
> > This is a standard Linux 3.0 kernel with sack and frto enabled.
> > Additional lab experiments have shown that following the path change, a
> > stream
> > of lost packets occurs (almost a full window, ~400kB). The receiver sends
> > dupacks on the new path to trigger fast retransmit, but then the
> > retransmission
> > timer on the sender side fires and all unacked data will be resent. At the
> > RTO,
> > we get the expected cwnd drop. While the receiver keeps kicking the the
> > sender
> > by sending dupacks, the retransmission is reasonably fast but after a few
> > ms it
> > grinds down to a stop-and-go behaviour.
> >
> > I failed in my efforts to find some explanation to this in the RFC's.
> > What i did find was in VJ's paper from '88.
> >
> > -When starting or restarting after a loss, set cwnd to one packet.
> > -On each ack for new data, increase cwnd by one packet
> >
> > If retransmitted data are not considered "new", that would explain the
> > behavior
> > i guess.
> >
> > Scripted ss -ti for the connection every 3 sec.
> > In this test it wasn't even a path change, we just downed the interface on
> > a
> > router in the middle for some 300ms to simulate the packetloss (This was
> > done at 15:06:18)
> >
> > Fri May 23 15:06:01 CEST 2014
> >         reno wscale:9,7 rto:1892 rtt:1678/7 ato:40 cwnd:2215 send 15.3Mbps
> > rcv_space:14480
> > Fri May 23 15:06:04 CEST 2014
> >         reno wscale:9,7 rto:1888 rtt:1678/8 ato:40 cwnd:2215 send 15.3Mbps
> > rcv_space:14480
> > Fri May 23 15:06:07 CEST 2014
> >         reno wscale:9,7 rto:1888 rtt:1676/9 ato:40 cwnd:2215 send 15.3Mbps
> > rcv_space:14480
> > Fri May 23 15:06:10 CEST 2014
> >         reno wscale:9,7 rto:1884 rtt:1675.5/5 ato:40 cwnd:2215 send
> > 15.3Mbps rcv_space:14480
> > Fri May 23 15:06:14 CEST 2014
> >         reno wscale:9,7 rto:1816 rtt:1607.5/22 ato:40 cwnd:2215 send
> > 16.0Mbps rcv_space:14480
> > Fri May 23 15:06:17 CEST 2014
> >         reno wscale:9,7 rto:1892 rtt:1681.5/7 ato:40 cwnd:2215 send
> > 15.3Mbps rcv_space:14480
> > Fri May 23 15:06:20 CEST 2014
> >         reno wscale:9,7 rto:1548 rtt:651/225 ato:40 cwnd:3 ssthresh:1107
> > send 53.4Kbps rcv_space:14480
> > Fri May 23 15:06:23 CEST 2014
> >         reno wscale:9,7 rto:1224 rtt:263/110 ato:40 cwnd:3 ssthresh:1107
> > send 132.1Kbps rcv_space:14480
> > Fri May 23 15:06:26 CEST 2014
> >         reno wscale:9,7 rto:1172 rtt:210.5/18 ato:40 cwnd:3 ssthresh:1107
> > send 165.1Kbps rcv_space:14480
> > Fri May 23 15:06:29 CEST 2014
> >         reno wscale:9,7 rto:1164 rtt:203.5/6 ato:40 cwnd:3 ssthresh:1107
> > send 170.8Kbps rcv_space:14480
> > Fri May 23 15:06:32 CEST 2014
> >         reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:3 ssthresh:1107
> > send 170.8Kbps rcv_space:14480
> > Fri May 23 15:06:35 CEST 2014
> >         reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107
> > send 341.5Kbps rcv_space:14480
> > Fri May 23 15:06:38 CEST 2014
> >         reno wscale:9,7 rto:1164 rtt:203.5/4 ato:40 cwnd:6 ssthresh:1107
> > send 341.5Kbps rcv_space:14480
> > Fri May 23 15:06:41 CEST 2014
> >         reno wscale:9,7 rto:1168 rtt:204/4 ato:40 cwnd:6 ssthresh:1107
> > send 340.7Kbps rcv_space:14480
> > Fri May 23 15:06:44 CEST 2014
> >         reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107
> > send 341.5Kbps rcv_space:14480
> > Fri May 23 15:06:47 CEST 2014
> >         reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107
> > send 341.5Kbps rcv_space:14480
> > Fri May 23 15:06:50 CEST 2014
> >         reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107
> > send 341.5Kbps rcv_space:14480
> > Fri May 23 15:06:53 CEST 2014
> >         reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107
> > send 341.5Kbps rcv_space:14480
> > Fri May 23 15:06:56 CEST 2014
> >         reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107
> > send 341.5Kbps rcv_space:14480
> > Fri May 23 15:06:59 CEST 2014
> >         reno wscale:9,7 rto:1164 rtt:203.5/4 ato:40 cwnd:6 ssthresh:1107
> > send 341.5Kbps rcv_space:14480
> > Fri May 23 15:07:02 CEST 2014
> >         reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:9 ssthresh:1107
> > send 512.3Kbps rcv_space:14480
> > Fri May 23 15:07:05 CEST 2014
> >         reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:9 ssthresh:1107
> > send 512.3Kbps rcv_space:14480
> > Fri May 23 15:07:08 CEST 2014
> >         reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:9 ssthresh:1107
> > send 512.3Kbps rcv_space:14480
> > Fri May 23 15:07:11 CEST 2014
> >         reno wscale:9,7 rto:1260 rtt:487.5/8 ato:40 cwnd:960 ssthresh:1107
> > send 22.8Mbps rcv_space:14480
> > Fri May 23 15:07:14 CEST 2014
> >         reno wscale:9,7 rto:1244 rtt:863.5/6 ato:40 cwnd:1111
> > ssthresh:1107 send 14.9Mbps rcv_space:14480
> > Fri May 23 15:07:17 CEST 2014
> >         reno wscale:9,7 rto:1148 rtt:864/6 ato:40 cwnd:1114 ssthresh:1107
> > send 14.9Mbps rcv_space:14480
> > Fri May 23 15:07:20 CEST 2014
> >         reno wscale:9,7 rto:1096 rtt:868/8 ato:40 cwnd:1118 ssthresh:1107
> > send 14.9Mbps rcv_space:14480
> >
> > On Thu, May 22, 2014 at 06:47:56AM +0000, Scheffenegger, Richard wrote:
> > >
> > > Are you perhaps observing an effect of the ACK clock loss, when you
> > refer to a huge number of consecutive lost segments?
> > >
> > > Standard SACK does suffer from an issue that during loss recovery, there
> > may be a gap (SACKs don't clock out new/retransmitted packets while
> > flightsize > cwnd (which is now 1/2); only during the 2nd half, SACK starts
> > to clock out packets, but at the same rate as before (which may not that
> > bright an idea if a path change with differnet characteristics is now
> > there).
> > >
> > > RateHalving (Linux has some kind of variant of this) / Proportional Rate
> > Reduction RFC6937 may be the thing that you are after?
> > >
> > >
> > > ABC really only comes into play during slowstart, to make connections
> > which use delayed ACKs not perform much less aggressive than sessions where
> > the receiver features QuickAck (Linux non-standard).
> > >
> > > Best regards,
> > >
> > >
> > > Richard Scheffenegger
> > >
> > >
> > > > -----Original Message-----
> > > > From: tcpm [mailto:[e-mail]] On Behalf Of Erik Hugne
> > > > Sent: Mittwoch, 21. Mai 2014 14:55
> > > > To: Mark Allman
> > > > Cc: [e-mail]; [e-mail];
> > > > [e-mail]
> > > > Subject: Re: [tcpm] RFC3465:TCP ABC and SACK'ed data
> > > >
> > > > On Wed, May 21, 2014 at 07:46:28AM -0400, Mark Allman wrote:
> > > > >
> > > > > > TCP ABC (still in the experimental track) defines a method to
> > > > > > increase the cwnd based on the bytes being acknowledged, instead of
> > > > > > the number of acks that arrive. I am assuming that SACK'ed
> > (RFC2018)
> > > > > > data should be included in this calculation, but i could find no
> > > > > > mention of this in RFC3465.  Could someone confirm this?
> > > > >
> > > > > ABC does not include SACK information in its calculations and it
> > > > > cannot include SACK information.  ABC applies to slow start---which
> > > > > ends when loss occurs.  And, (essentially) SACKs only arrive during
> > loss
> > > > recovery.
> > > > > So, there is no need for ABC to deal with SACKs.
> > > > >
> > > >
> > > > Thanks for taking the time to explain this.
> > > >
> > > > The problem (this is related to Ingemars posts around "Problem with low
> > > > SSthresh") is that following the path change, there is a large train of
> > > > segments being lost (say 150k out of a 500k window). Data at the end of
> > > > the window did make it through and is SACK'ed. Upon receiving these
> > SACK's
> > > > the sending side enters loss recovery. It will take a very long time
> > > > before recovering the 100k lost segments.
> > > >
> > > > An aggressive recovery algorithm would mitigate the effects of this,
> > but i
> > > > was hoping for a more elegant solution.
> > > >
> > > > //E
> > > >
> > > > _______________________________________________
> > > > tcpm mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/tcpm
> >
> > _______________________________________________
> > tcpm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tcpm
> >