Re: [tcpm] Review: draft-ietf-tcpm-early-rexmt-01

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Mark Allman wrote:
> Joe-
> 
> Thanks for the followup.  I am taking most of this as "Joe would have
> done it differently" and not as show-stoppers.  Please yell if this is
> not the case.

Just suggestions on clarifications that might be useful. No
show-stoppers. I think most of these can be addressed with brief bits of
text.

see below...

> But, in particular,
> 
>>> There is no "FR_thresh" sort of variable defined in RFC5681.  So, while
>>> I understand sort of what you are saying I think this ...
>>>
>>>     When the above two conditions hold and a TCP connection does not
>>>     support SACK the duplicate ACK threshold used to trigger a
>>>     retransmission MUST be reduced to:
>>>
>>> is clear about how one goes about using the threshold.  (This is an
>>> example ... there are other places with the same text.)
>> It's simpler than that - you have a variable called ER_thresh. You don't
>> define it. You explain what values to set it to, but you never use it to
>> do anything.
>>
>> I.e., you have an undefined variable that you set, but don't declare and
>> never use.
> 
> ...in a *program* we didn't write. :-)

Well, you wrote the lines that *set* the variable ;-))

> I think it is clear from the text what is going on here.  I.e., that
> "the duplicate ACK threshold used to trigger a retransmission MUST be
> reduced to: ER_thresh" is perfectly clear.

OK, so I missed this. It might be useful to make it more clear, e.g.,

	dupack_thresh = ER_thresh

(or whatever the dupack threshold variable name is)

> (ER_thresh is used in the text and so removing it as spurious is not the
> simple answer.)

I don't want to remove it. I just want to be more clear about using it.

>> Nagle is on by default. Your example should be very clear about the
>> fact that you expect the default to be overridden, or should include
>> Nagle IMO.
>>
>> I don't think you need many different cases, but if this works much
>> better with Nagle off, then the doc needs a bit of explanation on
>> this.
> 
> It's not a question or working better or worse with Nagle on or off.
> The examples are *illustrations* (advertised as such) of how a trivial
> estimation of the number of outstanding segments based on the number of
> bytes outstanding can be wrong (in both directions).  It is not meant to
> be any deeper than that.  It does not need to be complicated by
> extraneous details.

Can you just state that, i.e., "Nagle is off to simplify the example"?

> 
>>>> Other considerations: seems like you're making TCP send more
>>>> segments into the net when data is being lost, vs. the existing
>>>> mechanisms. If that's the case, and if loss is due to buffer
>>>> overload, are you making things potentially worse? If not, please
>>>> explain.
>>> I don't understand this point.  Is it relative to ER or [Bal98]?
>
>> Relative to not doing ER.
> 
> In that case I think you're wrong.  In the case of actual loss that loss
> is going to be repaired with a retransmit.  We send that retransmit at a
> different point than the existing mechanism (which would wait for the
> RTO to resend the exact same packet).  So, we are not sending more
> segments into the network.

I'm just suggesting it would be useful to include that answer. I didn't
know what it was, just that it wasn't addressed.

> I suppose that one could argue that by sending the segment sooner than
> the RTO we are perhaps not giving the congestion as much of a chance to
> clear from the router buffers.  But, that's a pretty thin argument given
> that fast retransmit does roughly the same thing and the network has not
> melted down because of it.  I'd rather just leave this as part of the
> experiment that would need to be done to put this on the standards track"

OK to also say "and this is expected to be confirmed by experiments".

> In the case of reordering (no actual loss; not the case you bring up
> above) then, yes, ER does inject more segments than necessary into the
> network.  That is shown in the appendix.  Also, that doesn't worry me as
> much because we are not sending those extra segments into obviously
> congested networks.

I'm not particularly worried, just asking that the issue be addressed  -
even briefly.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkq6OpAACgkQE5f5cImnZrvh9ACfa8z7QrPBMH78F777fkTG0gLE
5TkAnR15ZEeVOUNimtSW+drjqTL/UUeL
=/uXV
-----END PGP SIGNATURE-----