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

From: Michael Welzl <[email-masked]>
Date: Wed, 29 Aug 2012 16:21:00 +0200

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.

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.

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.

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?).

Cheers,
Michael