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

[Michael Welzl <[e-mail]>]

Hi,


On 5. sep. 2012, at 22:01, Nandita Dukkipati wrote:

> Michael, Apologies for the delay. These are good comments, here are
> some answers -
> 
> On Wed, Aug 29, 2012 at 7:21 AM, Michael Welzl <[e-mail]> 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.

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