Re: [tcpm] Some comments on 2581bis

> ** RFC 2581 & SACK
> Page 3 says:
>          Alternatively, a TCP that utilizes selective acknowledgments
>          [RFC2018,RFC2883] can determine an incoming ACK is a "duplicate"
>          if the ACK contains previously unknown SACK information.
> 
> And page 7 says:
> Note that a sender using SACK [RFC2018]
>          MUST NOT send new data unless the incoming duplicate
>          acknowledgment contains new SACK information.
> 
> IMHO, if you keep the "MUST NOT" in page 7, you'd probably
> s/can/MUST/ in page 3. Also, maybe it would be worth to clarify that
> the SACK information should be "in window"?

Well, duplicate ACKs in 2581 are not always to send out new data.

That said, I am wondering if we should just nuke the sentence you quote
above.  This document does not deal with SACK-based loss recovery and if
you have SACK then you should be doing something smarter than this
document.  And, so maybe we don't need to really define things about
SACK-based loss recovery in here.  Certainly, I don't think we want to
get into whether SACK blocks that this document doesn't use at all are
in window or not.

> ** Limits on dupacks
> Would it make sense to limit the number of accepted dupacks to
> Max_dupacks = (Flight_size_fr - 1) / SMSS ?
> where Flight_size_fr is the Flight_Size at the point fast retransmit
> is triggered.

I'd like to hear what people think on this notion.  The intent in
putting the new text in was not to tightly specify a mechanism, but to
note that there is good reason to put some sort of limit on things.  How
that is done does not seem important to me.  (*If* it is done only seems
marginally helpful to me.)  I.e., one could envision a cwnd limit or
trying (because we don't keep track in some stacks) to track the number
of packets vs. dupacks as above or ...

I guess I would rather leave it as sort-of fuzzy guidance and not
mechanism or just drop it as new functionality that is out of scope for
the revision.

What do folks think?

allman