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

["McAlpine, Gary" <[e-mail]>]

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:[e-mail]>
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>
=================================