Subject: Re: [tcpm] Question and comments about draft-dukkipati-tcpm-tcp-loss-probe

From: Nandita Dukkipati <[email-masked]>
Date: Wed, 5 Sep 2012 13:01:38 -0700

Michael, Apologies for the delay. These are good comments, here are
some answers -

On Wed, Aug 29, 2012 at 7:21 AM, Michael Welzl <[email-masked]> wrote:
> Hi,
>
> In an effort to address the CPM chairs' suggestion to clarify how draft-hurtig-tcpm-rtorestart related to draft-dukkipati-tcpm-tcp-loss-probe, I finally got around to reading the loss-probe draft - and I'm missing a key bit of information that would help me make the distinction (and would probably be good to include in your draft anyway - and: sorry if I missed it! but I think it's really not there): what is the rationale for your choice of "2 * SRTT" in the calculation of the probe timeout (PTO)? I mean, why not 3*RTT, 1.5*RTT, whatever? If this is just the result of measurements, it would be good to report that where you report the others.

The probe timeout or PTO value was not out of measurements but in fact
picked in the design/coding stage and we just stuck with it. The
reason for 2.RTT is approximately as follows: the sender should wait
long enough to know that an ACK is overdue. Under normal
circumstances, i.e. no losses, this would typically be one RTT. But
choosing PTO to be exactly an RTT is likely to generate spurious
probes given that even end-system timings can easily push an ACK to be
above an RTT. And hence I just chose it to be the next integral value
of RTT.

>
> On a side note, I also think that it would be helpful for the reader to know how you obtained the first results that you present, regarding the large difference between RTO and RTT, in the introduction (par. starting with "To get a sense...". I assume that this is the effect of a queue growing on a short flow, giving a large variance in the RTO calculation, but if that's what it is it would be good to say so.

This is a great question. The RTO and RTT values were measured by just
instrumenting the kernel. So right now it's just reporting the
measured values. I don't have a good answer on why the variance is
large - possibly queuing, or variance in mobile channels. Open
question.

>
> I also noticed an inconsistency: your draft is called "TCP Loss Probe", whereas the slides at http://www.ietf.org/proceedings/84/slides/slides-84-tcpm-14.pdf
> call it "Tail Loss Probe". Personally I prefer the latter term.

Good catch :) Changed my mind between the draft and presentation date.
We'll go with Tail loss probe.

>
> Finally, I think that this draft raises the obvious question: if it's beneficial to send an extra packet, why not 2, just to be safe? Or 3? Or ...   => surely there is a point of where things get unacceptable. It would be nice to see this trade-off quantified and evaluated, leading to a conclusion that explains why 1 probe packet is a good choice (or maybe even leading to a different number?).

In fact TLP v1 had no limit on number of probes sent prior to hitting
the RTO limit. And then an experiment showed sending just one probe
suffices to get most (~90%) of latency benefits. Hence our current
implementation limits to one probe; the draft allows up to two
consecutive probes. Agree that it's worthwhile documenting the
tradeoff.

Thanks for your read; will incorporate these in the next revision.

Nandita

>
> Cheers,
> Michael
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Michael Welzl <[email-masked]>
Date: Fri, 7 Sep 2012 09:00:13 +0200

Hi,

> above an RTT. And hence I just chose it to be the next integral value

That makes sense to me; it's good to know the rationale behind it, thanks.

Just a minor detail: because the logic behind RTO also says that an ACK is overdue, I would suggest setting PTO to min(RTO, 2*RTT). Sure, such a small RTO is not the case of concern for you, but I'm not sure it's really a corner case; perhaps? Either way, there will not a big difference in the resulting behavior, but taking the min probably just makes more sense.

Cheers,
Michael

---

From: Nandita Dukkipati <[email-masked]>
Date: Fri, 7 Sep 2012 12:18:03 -0700

> Just a minor detail: because the logic behind RTO also says that an ACK is overdue, I would suggest setting PTO to min(RTO, 2*RTT). Sure, such a small RTO is not the case of concern for you, but I'…

Agree, so if we are not able to schedule a PTO (Step 2 condition in
TLP algo. fails when RTO is not farther than PTO), we could just make
PTO to be a value smaller than RTO. There wouldn't be much point in
sending a probe if PTO is exactly RTO, so it does need to be strictly
smaller. Along similar lines we have been toying with an idea to push
out the RTO epoch farther by a sufficient value such that we always
get to schedule the lower impact PTO (still 2.RTT) before taking the
high impact RTO.