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

[Neal Cardwell <[e-mail]>]

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"?

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

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.

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

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?

best,
neal