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

[Yuchung Cheng <[e-mail]>]

Thank you Ben for your review. Here is the latest proposed diff. Let us
know what you think and we'll work w/ RFC editors to incorporate this minor
change.

On Wed, Dec 30, 2020 at 5:55 AM Neal Cardwell <[e-mail]> wrote:

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