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

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:tcpm-bounces@ietf.org] On Behalf Of Erik Hugne
> Sent: Mittwoch, 21. Mai 2014 14:55
> To: Mark Allman
> Cc: ingemar.s.johansson@ericsson.com; martin.isaksson@ericsson.com;
> tcpm@ietf.org
> 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
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm