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

[Mark Allman <[e-mail]>]

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.

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

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.

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

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

> >> 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 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
and not something that gates an experimental document.

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.

allman