Re: [tcpm] Problem with Low SSThresh (was I-D Action: draft-ietf-tcpm-newcwv-03.txt)

[Ingemar Johansson S <[e-mail]>]

Thanks for the response sofar

I run a TCP stack that is part of a larger LTE system simulator, I know that it is not a full match of e.g  a Linux TCP stack, I am trying to dig into the Linux TCP code as well as in ns2 code to see if something important is missing that makes my results unreliable, or if this is infact a flaw in how 

The setup:
1Mbps bottleneck, RTT ~35ms
Large FTP transfer (100MB)
No AQM, infinite buffer = bufferbloated network
Fake path change after 10s, packets are dropped for 100ms
	- Note! dropper after bottleneck

The chain of events that I see are 
1) DUPACKs received from from T~10.15 to T~14.2s
2) Fast retransmit at T=10.17s re-arms RTO timer (3.60s)
   2a) CWND restriction. Only one segment transmitted at T=17 the remaining segments transmitted at T = 12.18s due to CWND restriction, but RTO timer not restarted at T=12.18 because of loss recovery state
3. Retransmission timeout at T=13.78s  DUPACK counter and SACK scoreboard is reset
4. DUPACK counter=3 at T=13.81s  fast retransmit, SSThresh set to 2MSS !

I have a few slides that show more detail, I can email them to anyone interested. 
A questions: 
In my code the DUPACK counter and the SACK scoreboard is reset  at retransmission timeout and this is what causes SSThresh to drop to  2MSS in this case. Is this a bug in my code or that it is too simplistic ?, or is it just the way it should be ?. 

I am thankful for any pointers to a more comprehensible documentation on how e.g a Linux TCP stack behaves.

Now I believe that bufferbloat is at least partly to blame for this, but I am not yet convinced that it is the full story.

Regards
/Ingemar



> -----Original Message-----
> From: Gorry Fairhurst [mailto:[e-mail]]
> Sent: den 16 maj 2014 15:49
> To: McAlpine, Gary; Ingemar Johansson S; [e-mail]
> Cc: Karen E. E. Nielsen
> Subject: Re: Problem with Low SSThresh (was I-D Action: draft-ietf-tcpm-
> newcwv-03.txt)
> 
> Yes - this seems like an oversight in the way ssthresh was conceived.
> The value is intended to capture congestion history, and hence it's nice to
> cache this for new flows to  prevent them overshooting the bottleneck
> capacity. I can think of 3 things where current ssthresh methods give
> unwarranted poor performance:
> 
>   - path changes, presumably uncommon.
>   - historic information (an event hours ago has little bearing on a long-lived
> connection and is a real impediment when the RTT is large).
>   - non-congestion loss (especially when FS was small)
> 
> Gorry
> 
> On 15/05/2014 18:21, McAlpine, Gary wrote:
> > Hi Ingemar,
> >
> > I'm not sure what the rational was for dropping ssthresh to 2*MSS, but it
> seems to me that there are too many non-congestion-related events that
> can cause this extreme setting of ssthresh. Once ssthresh gets set so low,
> the real problem we have seen is recovery on long-lived connections or
> where an ssthresh-host-cache is in use. In these cases, the current
> congestion RFCs don't provide a specific mechanism for ssthresh to recover
> to a level that represents the actual congestion level. So what we have seen
> are connections between a particular client and server go to very low
> throughput and not recover for a very long time. In fact, the traffic between
> the client and server may be such that it can never recover until the
> connection is dropped (in the case of a long-lived connections) or the cached
> ssthresh is reset.
> >
> > To allow our customers to avoid this problem, we have provided two
> mechanisms in our software:
> >
> >
> > 1.       They can disable ssthresh-host-cache so that new connections will
> always restart ssthresh.
> >
> > 2.       Since RFC 5681 paragraph 4.1 is silent on what to do with ssthresh
> when restarting idle connections, we assume ssthresh is no longer valid after
> a sufficiently long idle period. Given the next transfer is going to perform a
> slow-start that will (essentially) search for the appropriate cwnd level and
> restart the ack clock,  we also restart ssthresh so that the appropriate cwnd
> level can be found.
> >
> > These mechanisms seem to work quite well and we haven't seen any cases
> where they have caused other problems, but I would be much happier if the
> congestion RFCs were not so silent on what to do with ssthresh to recover
> from cases where ssthresh gets set to an inappropriately low level.
> >
> > Thanks,
> > Gary
> >
> >
> >
> > From: Ingemar Johansson S [mailto:[e-mail]]
> > Sent: Tuesday, May 13, 2014 1:15 AM
> > To: [e-mail]
> > Cc: Karen E. E. Nielsen; [e-mail]; McAlpine, Gary
> > Subject: Problem with Low SSThresh (was I-D Action:
> > draft-ietf-tcpm-newcwv-03.txt)
> >
> > Hi
> >
> > Karen pointed out this thread to me
> > http://www.ietf.org/mail-archive/web/tcpm/current/msg08315.html
> > I started to look closer at this issue quite recently, the problem I have is
> that SSthresh can drop to very low values after only a few lost packets. I have
> seen this odd effect earlier but have not bothered with it.
> >
> >
> > The experiment is to run a large FTP transfer over a 1Mbps bottleneck with
> min RTT = 40ms. No AQM or tail drop queue enabled i.e a buffer bloated
> scenario.
> >
> > TCP NewReno. After 10s I "pull the plug" for 100ms (100% packet drop), this
> leads to 5 lost segments. at T =10.1s packets are forwarded as usual.
> >
> > What I have seen is that a retransmission timeout is immediately followed
> by a loss event, the effect of which is that SSThresh goes down to 2 MSS.  It
> seems to me that the RTO timer value is too low, I have not understood the
> effect completely though. Could the RTO timer be the culprit or is there
> some other effect ?.
> >
> > I am running these experiments in a proprietary LTE system simulator, we
> try to keep it up to date to match the Linux TCP stack reasonably well, it
> cannot be ruled out however that our implementation miss some important
> feature.
> >
> > /Ingemar
> >
> > =================================
> > Ingemar Johansson  M.Sc.
> > Senior Researcher
> >
> > Ericsson AB
> > Wireless Access Networks
> > Labratoriegränd 11
> > 971 28, Luleå, Sweden
> > Phone [phone]
> > SMS/MMS [phone]
> >
> [e-mail]<mailto:ingemar.s.johansson@ericsson.c
> > om>
> > www.ericsson.com
> >
> > "Those are my principles, and if you don't like them...
> > well, I have others."  Groucho
> >
> Marx<http://www.brainyquote.com/quotes/authors/g/groucho_marx.html
> >
> > =================================
> >
> >
> >