Re: [Last-Call] Genart last call review of draft-ietf-tcpm-rto-consider-14

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Stewart,

If there are no further objections, I'm going to declare consensus.

On Thu, Jun 11, 2020 at 1:45 PM Martin Duke <martin.h.duke@xxxxxxxxx> wrote:
Stewart,

do we need more cycles for this, or is draft-15 sufficient to address your concerns?

On Mon, Jun 8, 2020 at 12:52 PM Mark Allman <mallman@xxxxxxxx> wrote:

Hi Stewart, et.al.!

I just submitted a new version of rto-consider.  Please ask the
datatracker for diffs between this and rev -14.  The highlights:

  - The diffs with the last rev are here: https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tcpm-rto-consider-15.txt

  - All small comments addressed.

  - I think we all agree that this is not a one-size-fits-all
    situation.  Rather, this document is meant to be a default case.
    So, the main action of this rev is to make that point more
    clearly.  The first paragraph in the intro is new.  Also, there
    are some more words fleshing out the context more in section 2.
    In particular, more emphatically making the point that other
    loss detectors are fine for specific cases.

  - The first paragraph in the intro also makes clear we adopt the
    loss == congestion model (as that is the conservative default,
    not because it is always true).

  - I made one other change that wasn't exactly called for, but
    seems like an oversight.

    Previously guideline (4) said loss MUST be taken as an
    indication of congestion and some standard response taken.  But,
    this guideline has an explicit exception for cases where we know
    the loss was caused by some non-congestion event.  Guideline (3)
    says you MUST backoff.  But, it did not have this exception for
    cases where we can tell the cause.  But, I think based on the
    spirit of (4), (3) should also have these words.  So, I added
    them.

    Also, I swapped (3) and (4) because it seemed more natural in
    re-reading to first think about taking congestion action and
    then dealing with backoff.  I think the ordering is a small
    thing, but folks can yell and I'll put it back if there is
    angst.

Please take a look and let me know if this helps things along or
not.

allman
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux