Re: [Last-Call] Tsvart last call review of draft-ietf-6man-hbh-processing-15

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Apr 29, 2024, at 4:04 AM, Brian Trammell via Datatracker <noreply@xxxxxxxx> wrote:

in Section 4: "Significant reordering of the packets belonging to a flow can
impact the performance of upper layer protocols and needs to be avoided." The
first part of this is obviously true. The second part is mostly true for most
protocols in most of the Internet, but I'm not sure "needs to be avoided" is
universally true for all transports. In the absence of any good way to know how
reordering-tolerant a given flow is, I'm not sure I have advice for making this
text better, but it makes me feel a little sad nonetheless.

Also from Sec 4 Background:

If a subset of packets in a flow were to include Hop-by-Hop options, this could introduce a potential for packets to be delivered out of order to the destination.

I agree with Brian - out of order risk comes with the use of IP. IP alone can’t fix this and we don’t want to impose this expectation on either routing protocols (due to multi path) or link/tunnel layers.

Suggest replacing “induce the potential for l” with “increase the number and distances of"

Same section, later:

Significant reordering of the packets belonging to a flow can impact the performance of upper layer protocols and needs to be avoided

Perhaps replacing “Significant reordering” with “iIncreasing se the number of out of order packets and distance of the reordering”.

Note too that the impact isn’t just to upper layer protocols (e.g., L4); there’s an impact to IPsec (replay window) and IP fragmentation reassembly when the distance of reordering is increased.

Joe

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux