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

[Mark Allman <mallman at icir.org>]

> as requested at the last TCPM meeting in Stockholm that we need some
> reviews for Early Retransmit (draft-ietf-tcpm-early-rexmt-01), here
> are some comments from me:

Many thanks for the comments!

> * The "entry point" of the algorithm could be better described. For
> * example lets begin paragraph 2 in section 2.1 as follows: When an
> * acknowledgment arrives at the sender, the sender ...

I don't entirely understand where you're talking about in section 2.1.
The above sentence fragment does not look like it meshes well with any
of the paragraphs that I can identify that you might be talking about.
I am going to take this for a nit and ignore it for now.  If this is
more than stylistic please send a more verbose change request.

> * What about RFC4653 - Improving the Robustness of TCP to Non-
> Congestion Events? Is Early Retransmit compatible to RFC4653? At
> first  glance I think yes, when we define a priority which algo
> should alter  Dupthresh

We don't need a priority.  The algorithms operate in different regions
of the operating space.  I put the following paragraph in the related
work section:

    [RFC4653] also defines an orthogonal method for altering the
    duplicate ACK threshold.  The mechanisms proposed in this document
    decrease the duplicate ACK threshold when a small amount of data is
    outstanding.  Meanwhile, the mechanisms in [RFC4653] increase the
    duplicate ACK threshold (over the standard of 3) when the congestion
    window is large in an effort to increase robustness to packet
    reordering.


> * Section 1, para 3: s/Small windows/Small congestion windows/

Done.

> * Section 1, last para: Explanation of the difference between
> * Limited  Transmit and Early Retransmit. Maybe we can put here a
> * pointer to the  aforementioned case why a CWND can be small. For
> * example (last  sentence): The "Early Retransmit" mechanism
> * outlined in this document  covers the case when previously unsent
> * data is not available (case 2)  for transmission or cannot be
> * transmitted due to an advertised window  limitation (case 1).

I did this, but instead of "case 1" I used "case 3" which is what I
believe you meant.

allman

Attachment: pgpuHCt6xmOmU.pgp
Description: PGP signature