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

[Neal Cardwell <[e-mail]>]

On Wed, Dec 30, 2020 at 12:42 AM Benjamin Kaduk <[e-mail]> wrote:

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

Great. Thanks for raising this issue!


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

Right, exactly. If there are no retransmissions and the sequence of packet
deliveries is [1, 3, 4, 5, 2] then my intuition and
RACK_detect_reordering() would not conclude that 3, 4, 5 are "reordering",
but upon seeing that 2 is delivered both my intuition
an  RACK_detect_reordering() would declare that reordering has been seen.



> > 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.


Great. Glad to hear it. We will talk it over among the draft co-authors and
see if we can make this more clear.

Thanks!

neal