| Hi,
JFYI, I brought this issue regarding RACK up on the TCPM mailing list today. Because all responses are in line, it reads well in this combined email. Neal cut away some text in his last response, which I just copied in at the bottom so it can all be read in a single email.
Cheers, Michael
Begin forwarded message:
Subject: Re: [tcpm] TLP pto scheduling
Date: October 12, 2017 at 8:55:35 AM GMT+2
Hi,
On Oct 12, 2017, at 8:33 AM, Neal Cardwell <
" class="">
> wrote:
On Thu, Oct 12, 2017 at 5:43 AM, Michael Welzl <
" class="">
> wrote:
While we’re at it - I have a question about RACK and TLP too:
Say, we have a cwnd of 100 segments and hit heavy congestion: all packets are lost.
ssthresh becomes 50, or 70 in case of Cubic. A TLP timer would fire, and let’s say that this one single packet would make it. Because an ACK arrives, the sender would stay in FR, and from the resulting SACK info, RACK would know that this was much later than all the previous packets, and hence would immediately send out a burst (maybe paced, but that’s another story) of 50 or 70 packets, right?
Have I understood this correctly? If so, isn’t this a pretty aggressive behavior? I mean, we have one RTT of losing everything, a probe timer later we get one packet through, and then we have so many packets again, straight away after this long pause… this may or may not be the right thing to do. As you know I like the RACK idea, but if it can turn out to be as aggressive as that, I would appreciate evaluation results showing that this doesn’t become a problem (and if it does become a problem, some limitations could be put in place). I don’t think we’ve seen this type of evaluation so far.
Good question. We cover that kind of question (with an example very close to yours) in section 7.5, "Interaction with congestion control", in: https://tools.ietf.org/html/draft-ietf-tcpm-rack-02
Ah, right - sorry for missing this (I had read this section once, but forgot about it).
At a high level, we feel that what the sender does when it gets a
small number of packets SACKed that indicate a large number of packet
lost is a congestion control decision, which we feel should be
considered to be decoupled (as much as possible) from the loss
detection logic in RACK.
That makes sense to me - although I think we do need a concrete default recommendation on what to do (in the absence of any better solutions, e.g. pacing or whatever, ..).
That said, as we mention in the draft, we recommend combining RACK
with PRR [RFC6937]. After receiving the SACK for the TLP probe packet,
at which point RACK marks the whole rest of the flight lost, PRR would
not send a burst, but rather would slow-start, starting from 1 packet
(1, 2, 4, 8....).
Yes, this is nicely explained in section 7.5, and it seems to me to be a reasonable thing to do.
The recommendation to use PRR is kinda there, but IMO a bit too weak: *** A packet marked lost by RACK SHOULD NOT be retransmitted until congestion control deems this appropriate (e.g. using [RFC6937]). ***
What about, e.g.: *** A packet marked lost by RACK SHOULD NOT be retransmitted until congestion control deems this appropriate. Specifically, Proportional Rate Reduction [RFC6937] SHOULD be enabled when using RACK. ***
Thanks, Michael. That sounds good to me. CC-ing my co-authors to get
their sense.
BTW, this has been the behavior of TLP-initiated recovery in Linux TCP
since our team added it in March of 2013. (Back then Linux TCP was
using TLP + FACK + PRR; now it's with TLP + RACK + PRR.)
neal
|