Re: [tcpm] Benjamin Kaduk's No Objection on draft-ietf-tcpm-rack-14: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Neal,

On Tue, Dec 29, 2020 at 11:04:41PM -0500, Neal Cardwell wrote:
> On Tue, Dec 29, 2020 at 3:07 PM Benjamin Kaduk <[e-mail]> wrote:
> 
> > > > Section 3.3.2
> > > >
> > > >    1.  The reordering window SHOULD be set to zero if no reordering has
> > > >        been observed on the connection so far, and either (a) three
> > > >        segments have been delivered out of order since the last
> > recovery
> > > >
> > > > I assume there's some subtle technical difference between "reordering"
> > > > and "segments delivered out of order" that makes this a reasonable
> > thing
> > > > to say ... but it would be nice if the distincion was made more clear
> > > > (whether here or in earlier text).
> > > >
> > > Great idea to define reordering more precisely. In this document,
> > > reordering refers to when two TCP segments are delivered at the TCP
> > > receiver in a different order from they were sent at the TCP sender for a
> > > given TCP flow. Notice the ordering is chronological instead of
> > sequential
> > > on TCP sequences.
> > >
> > > We'll add that definition on the first appearance of the word
> > 'reordering'
> > > to clarify.
> >
> > I am quite confident that you know how this works, though I am not sure
> > that I understand properly yet -- is the key distinction that "reordering
> > has been observed" and "segments have been delivered out of order" refer to
> > time vs TCP sequence number?  (There's not actually a need to respond; I am
> > sure the document will be correct.  I am just curious, is all.)
> >
> 
> Benjamin, I think I did not previously understand your earlier remark: 'I
> assume there's some subtle technical difference between "reordering"
> and "segments delivered out of order" that makes this a reasonable thing to
> say... '
> 
> But now I think perhaps I understand what you were getting at: were you
> remarking that there is an apparent contradiction in the text between "no
> reordering has been observed on the connection so far" and "three segments
> have been delivered out of order", so that it seems impossible for the
> connection to meet the conditions for both "no reordering has been observed
> on the connection so far" and "(a) three segments have been delivered out
> of order since the last recovery"?

Exactly so!  Sorry for not having been more clear originally.

> I agree that the text of the draft as currently written seems contradictory
> or at least unclear. :-)

Well, I guess I can feel better about having been confused by it, now :)

> The "three segments have been delivered out of order" phrase in the draft
> was meant to refer to three segments being SACKed. But now that you raise
> this point, it seems to me it would be more correct and clear to say
> something like "three segments have been SACKed", rather than "three
> segments have been delivered out of order".
> 
> From my perspective, the SACKed segments are not necessarily "delivered out
> of order", they merely have at least one hole in the sequence space. For
> example, in the sequence [1, 3, 4, 5], the [3, 4, 5] are not "out of
> order", and were they TCP segments we would not say that reordering has
> been observed; it's just that 2 is not (yet?) present.

Indeed, there is some subjectivity in the definition of "out of order".
(My initial draft comments on this document had included a request for more
clarity on how to tell which segments are "out of order" as compared to
some baseline, but I deleted it once I got to, IIRC, discussion in Section
6.2 about segments below RACK.fack getting acknowledged as being ones
delivered out of order, which I took to be effectively a definition, and
seemed well-formed at the time.  Though perhaps that formulation is not
well-defined for what it means for a retransmitted segment to be
out-of-order...)  If we apply the definition of "a segment is delivered out
of order if, when it is ACKd, RACK.fack is greater than its sequence
number" to your example above, it seems like we would conclude that 2 is out
of order, but 3, 4, and 5 are in-order.  (Right?)

> I also like the "three segments have been SACKed" phrase since the "have
> been SACKed" phrase is used in RFC6675 for a similar purpose in the
> description of "IsLost (SeqNum):"

Also a pretty compelling argument.

> If it's not too late for edits, I would propose that the section you
> mentioned ("3.3.2
> <https://tools.ietf.org/html/draft-ietf-tcpm-rack-15#section-3.3.2>.
> Reordering window adaptation") that says:
> 
>    1.  The reordering window SHOULD be set to zero if no reordering has
>        been observed on the connection so far, and either (a) three
>        segments *have been delivered out of order* since the last recovery
>        or (b) the sender is already in fast or RTO recovery.
> 
> 
> would be edited to:
> 
> 
>    1.  The reordering window SHOULD be set to zero if no reordering has
>        been observed on the connection so far, and either (a) three
>        segments *have been SACKed* since the last recovery
>        or (b) the sender is already in fast or RTO recovery.
> 
> 
> Benjamin, does that help address what you were talking about?

Yes.  From my point of view, that proposal is a big improvement.

Thanks,

Ben