On Mon, Apr 29, 2024 at 8:14 AM touch@xxxxxxxxxxxxxx <touch@xxxxxxxxxxxxxx> wrote: > > 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. In order delivery, especially in datacenter networks, is a currently ubiquitous but implicit requirement. The best way for a host to promote in order delivery is to make all the packets in a flow look the same to routers as much as possible. For instance, if someone is using the PathMTU HBH option it's better to set the option in every packet as opposed to setting it in every Nth packet. The problem with OOO is that the most likely effect is to increase the variance in RTT which adversely impacts transport protocol performance. Tom > > 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 > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@xxxxxxxx > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
