[Int-area] Re: [IPsec] New Version Notification for draf t-white-intarea-reordering-04.txt
Joe Touch <[email protected]> Mon, 3 Aug 2026 19:09:22 -0700
| Newsgroups | gmane.ietf.int,gmane.ietf.tsvwg,gmane.ietf.ipsec |
|---|---|
| Message-ID | <[email protected]> |
--===============4663714939944771479== Content-Type: multipart/alternative; boundary="Apple-Mail=_D668AB57-2E1F-48C6-BAD5-7D2146A1B825" --Apple-Mail=_D668AB57-2E1F-48C6-BAD5-7D2146A1B825 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FWIW, IMO reordering and resquencing are synonymous. I would not expect = readers to track the difference, even if coined as different in this = document. I would encourage =E2=80=9Cmisordering=E2=80=9D as a more reliably = interpreted term for changing the order of packets from their arrival. Also note: reordering and resequencing both could mean EITHER =E2=80=9Cput= ting things in the correct order=E2=80=9D or =E2=80=9Cputting things = back to the order in which they arrived=E2=80=9D (which may not be = correct). Delay is added whenever EITHER type of reordering/resequencing occurs - = or (notably) when misordering occurs in the first place. Another type of delay that midpoint nodes should not try to correct is = jitter, i.e., variation in the arrival of a packet stream. Again, any = attempt to change the arrival pattern necessarily introduces delay - as = does anything that increases that variation. I.e., the doc focuses on situations where the endpoint could allow = packets to arrive out of order, but that=E2=80=99s not the only reason = to avoid resequencing. Joe=20 > On Aug 3, 2026, at 4:51=E2=80=AFPM, Greg White = <[email protected]> wrote: >=20 > Hi Joe, > =20 > Thanks for the detailed feedback, this is very helpful. We will try to = tackle as many of these suggestions as we can in the next version. > =20 > For clarity, in the draft we defined the terms =E2=80=9Creordering=E2=80= =9D =3D making packet out of order, =E2=80=9Cresequencing=E2=80=9D =3D = putting them back in order. To help avoid confusion, I=E2=80=99ve = edited your points to align with this terminology - with square brackets = where I=E2=80=99ve made a change. > =20 > On your final point that it isn=E2=80=99t clear that this document is = saying anything different from RFC3819: yes, the two excerpts you quoted = aren=E2=80=99t markedly different, and Section 1 paragraph 2 = <https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.html#se= ction-1-2> indicates that the main issue with RFC3819 isn=E2=80=99t that = statement, it is the text that follows. Also, I think we=E2=80=99ll end = up with more concrete recommendations than what are in the draft = currently. > =20 > -Greg > =20 > =20 > From: Joe Touch <[email protected] <mailto:[email protected]>> > Date: Monday, August 3, 2026 at 8:42=E2=80=AFAM > To: Greg White <[email protected] <mailto:[email protected]>> > Cc: Internet Area <[email protected] <mailto:[email protected]>>, = "[email protected] <mailto:[email protected]>" <[email protected] = <mailto:[email protected]>>, "[email protected] <mailto:[email protected]>" = <[email protected] <mailto:[email protected]>> > Subject: Re: [IPsec] New Version Notification for = draft-white-intarea-reordering-04.txt > =20 > Hi, all, > =20 > Although the new and updated information provided in this document = could be useful, it=E2=80=99s not clear that this document supersedes = any of the advice provided in RFC 3819. > =20 > Additionally, it omits key information as to why layer 2 frame = ordering is maintained in certain protocols. > =20 > In particular: > - the abstract describes that [resequencing] =E2=80=9Ccan introduce = delays that result in net degradation of performance=E2=80=9D. Those = delays can also be irrelevant, e.g., if no further [resequencing] occurs = and the receiver [resequences] anyway (as with TCP). The lack of such = [resequencing] can also increase work at the receiver, as when TCP sends = SACK rather than cumulative ACK. I.e., the impact is not always clear. > =20 > - on-path interpretation of TCP streams, including DPI, don=E2=80=99t = always react as well as modern TCP endpoints > =20 > - the impact on fragmentation and reassembly is not addressed = sufficiently; the discussion should cite the primary requirements (791, = 8200) and go into a bit more detail. > =20 > - IPsec is clearly sensitive to reordering. Most protocols, TCP = included, can adapt to some level of reordering only up to a limit. Not = only are there limits, but (as noted above) there is a cost at the = receiver to support these capabilities. This doesn=E2=80=99t appear to = be addressed. > =20 > - there are MANY variations to TCP as deployed, as well as other = protocols. Implementations with compromised resources, such as in IoT or = low-power devices, may not all be up to =E2=80=9Cmodern=E2=80=9D = standards. > =20 > - there are protocols that require ordering at L2 (ATM being the = primary example); it is useful to reiterate that this document isn=E2=80=99= t recommending a change that would violate other L2 semantics that = depend on ordering. > =20 > AFAICT, the only clear requirements here are: > =20 >> Subnetwork implementers SHOULD avoid introducing unnecessary packet = reordering. However, where packet reordering is an unavoidable = consequence of mechanisms that improve overall performance or = reliability (for example, packet striping across multiple links or = link-layer retransmissions), the resulting packet reordering SHOULD = generally be exposed to the receiving endpoint rather than hidden by = subnetwork resequencing. >>=20 > RFC3819 says: > =20 > This suggests that subnetwork implementers should try to avoid = packet > reordering whenever possible, but not if doing so compromises > efficiency, impairs reliability, or increases average packet delay. > =20 > It isn=E2=80=99t clear that this document is saying anything different = from RFC3819. > =20 > It may be useful as informational, but as presented it isn=E2=80=99t = clear it should be a BCP; at best, it is an informative update to the = context in which RFC3819 recommendations remain valid. > =20 > Joe >=20 >=20 >> On Jul 7, 2026, at 9:19=E2=80=AFAM, Greg White = <[email protected] = <mailto:[email protected]>> wrote: >> =20 >> FYI >>=20 >> On 7/6/26, 5:25 PM, "[email protected] = <mailto:[email protected]> <mailto:[email protected]>" = <[email protected] <mailto:[email protected]> = <mailto:[email protected]>> wrote: >>=20 >>=20 >> A new version of Internet-Draft draft-white-intarea-reordering-04.txt = has been >> successfully submitted by Greg White and posted to the >> IETF repository. >>=20 >>=20 >> Name: draft-white-intarea-reordering >> Revision: 04 >> Title: Proposal for Updates to Guidance on Packet Reordering >> Date: 2026-07-06 >> Group: Individual Submission >> Pages: 12 >> URL: = https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.txt = <https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.txt> >> Status: = https://datatracker.ietf.org/doc/draft-white-intarea-reordering/ = <https://datatracker.ietf.org/doc/draft-white-intarea-reordering/> >> HTML: = https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.html = <https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.html> >> HTMLized: = https://datatracker.ietf.org/doc/html/draft-white-intarea-reordering = <https://datatracker.ietf.org/doc/html/draft-white-intarea-reordering> >> Diff: = https://author-tools.ietf.org/iddiff?url2=3Ddraft-white-intarea-reordering= -04 = <https://author-tools.ietf.org/iddiff?url2=3Ddraft-white-intarea-reorderin= g-04> >>=20 >>=20 >> Abstract: >>=20 >>=20 >> Several link technology standards mandate that equipment guarantee >> in-order delivery of layer 2 frames, apparently due to a belief that >> this is required by higher layer protocols. To meet this requirement >> they implement a "resequencing" operation to restore the original >> packet order. This can introduce delays that result in net >> degradation of performance. Modern TCP and QUIC implementations >> support features that significantly improve their tolerance to out- >> of-order delivery. This draft is intended to provide new information >> for layer 2 technology standards regarding the need to assure in- >> order delivery to support IETF protocols. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> IPsec mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] = <mailto:[email protected]> > =20 > _______________________________________________ > IPsec mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] = <mailto:[email protected]> --Apple-Mail=_D668AB57-2E1F-48C6-BAD5-7D2146A1B825 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" = content=3D"text/html; charset=3Dutf-8"></head><body = style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; = line-break: after-white-space;">FWIW, IMO reordering and resquencing are = synonymous. I would not expect readers to track the difference, even if = coined as different in this document.<div><br></div><div>I would = encourage =E2=80=9Cmisordering=E2=80=9D as a more reliably interpreted = term for changing the order of packets from their = arrival.</div><div><br></div><div>Also note: reordering and resequencing = both could mean EITHER =E2=80=9Cputting things in the correct order=E2=80=9D= or =E2=80=9Cputting things back to the order in which they arrived=E2=80=9D= (which may not be correct).</div><div><br></div><div>Delay is added = whenever EITHER type of reordering/resequencing occurs - or (notably) = when misordering occurs in the first = place.</div><div><br></div><div>Another type of delay that midpoint = nodes should not try to correct is jitter, i.e., variation in the = arrival of a packet stream. Again, any attempt to change the arrival = pattern necessarily introduces delay - as does anything that increases = that variation.</div><div><br></div><div>I.e., the doc focuses on = situations where the endpoint could allow packets to arrive out of = order, but that=E2=80=99s not the only reason to avoid = resequencing.</div><div><br></div><div>Joe </div><div><div><br><block= quote type=3D"cite"><div>On Aug 3, 2026, at 4:51=E2=80=AFPM, Greg White = <[email protected]> wrote:</div><br = class=3D"Apple-interchange-newline"><div><meta charset=3D"UTF-8"><div = class=3D"WordSection1" style=3D"page: WordSection1; caret-color: rgb(0, = 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = orphans: 2; text-align: start; text-indent: 0px; text-transform: none; = white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration-line: none; = text-decoration-thickness: auto; text-decoration-style: solid;"><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><span style=3D"font-size: 11pt;">Hi = Joe,<o:p></o:p></span></div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;"><span style=3D"font-size: = 11pt;"><o:p> </o:p></span></div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif;"><span = style=3D"font-size: 11pt;">Thanks for the detailed feedback, this is = very helpful. We will try to tackle as many of these suggestions as we = can in the next version.<o:p></o:p></span></div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span = style=3D"font-size: 11pt;"><o:p> </o:p></span></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><span style=3D"font-size: 11pt;">For clarity, in the draft = we defined the terms =E2=80=9Creordering=E2=80=9D =3D making packet out = of order, =E2=80=9Cresequencing=E2=80=9D =3D putting them back in order. = To help avoid confusion, I=E2=80=99ve edited your points to align = with this terminology - with square brackets where I=E2=80=99ve made a = change.<o:p></o:p></span></div><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, sans-serif;"><span style=3D"font-size: = 11pt;"><o:p> </o:p></span></div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif;"><span = style=3D"font-size: 11pt;">On your final point that it isn=E2=80=99t = clear that this document is saying anything different from RFC3819: yes, = the two excerpts you quoted aren=E2=80=99t markedly different, and<span = class=3D"Apple-converted-space"> </span><a = href=3D"https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.= html#section-1-2" style=3D"color: rgb(70, 120, 134); text-decoration: = underline;">Section 1 paragraph 2</a><span = class=3D"Apple-converted-space"> </span>indicates that the main = issue with RFC3819 isn=E2=80=99t that statement, it is the text that = follows. Also, I think we=E2=80=99ll end up with more concrete = recommendations than what are in the draft = currently.<o:p></o:p></span></div><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, sans-serif;"><span style=3D"font-size: = 11pt;"><o:p> </o:p></span></div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif;"><span = style=3D"font-size: 11pt;">-Greg<o:p></o:p></span></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><span style=3D"font-size: = 11pt;"><o:p> </o:p></span></div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif;"><span = style=3D"font-size: 11pt;"><o:p> </o:p></span></div><div = style=3D"border-width: 1pt medium medium; border-style: solid none none; = border-color: rgb(181, 196, 223) currentcolor currentcolor; = border-image: none; padding: 3pt 0in 0in;"><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif;"><b><span = style=3D"font-family: Calibri, sans-serif;">From:<span = class=3D"Apple-converted-space"> </span></span></b><span = style=3D"font-family: Calibri, sans-serif;">Joe Touch <<a = href=3D"mailto:[email protected]" style=3D"color: rgb(70, 120, 134); = text-decoration: = underline;">[email protected]</a>><br><b>Date:<span = class=3D"Apple-converted-space"> </span></b>Monday, August 3, 2026 = at 8:42=E2=80=AFAM<br><b>To:<span = class=3D"Apple-converted-space"> </span></b>Greg White <<a = href=3D"mailto:[email protected]" style=3D"color: rgb(70, 120, 134); = text-decoration: = underline;">[email protected]</a>><br><b>Cc:<span = class=3D"Apple-converted-space"> </span></b>Internet Area <<a = href=3D"mailto:[email protected]" style=3D"color: rgb(70, 120, 134); = text-decoration: underline;">[email protected]</a>>, "<a = href=3D"mailto:[email protected]" style=3D"color: rgb(70, 120, 134); = text-decoration: underline;">[email protected]</a>" <<a = href=3D"mailto:[email protected]" style=3D"color: rgb(70, 120, 134); = text-decoration: underline;">[email protected]</a>>, "<a = href=3D"mailto:[email protected]" style=3D"color: rgb(70, 120, 134); = text-decoration: underline;">[email protected]</a>" <<a = href=3D"mailto:[email protected]" style=3D"color: rgb(70, 120, 134); = text-decoration: underline;">[email protected]</a>><br><b>Subject:<span = class=3D"Apple-converted-space"> </span></b>Re: [IPsec] New Version = Notification for = draft-white-intarea-reordering-04.txt<o:p></o:p></span></div></div><div><d= iv style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif;">Hi, = all,<o:p></o:p></div><div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;"><o:p> </o:p></div></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Although the new and updated information provided in this = document could be useful, it=E2=80=99s not clear that this document = supersedes any of the advice provided in RFC = 3819.<o:p></o:p></div></div><div><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">Additionally, it = omits key information as to why layer 2 frame ordering is maintained in = certain protocols.<o:p></o:p></div></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">In = particular:<o:p></o:p></div></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif;">- the abstract = describes that [resequencing] =E2=80=9Ccan introduce delays that result = in net degradation of performance=E2=80=9D. Those delays can also be = irrelevant, e.g., if no further [resequencing] occurs and the receiver = [resequences] anyway (as with TCP). The lack of such [resequencing] can = also increase work at the receiver, as when TCP sends SACK rather than = cumulative ACK. I.e., the impact is not always = clear.<o:p></o:p></div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;"><span style=3D"font-size: = 11pt;"><o:p> </o:p></span></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">- on-path = interpretation of TCP streams, including DPI, don=E2=80=99t always react = as well as modern TCP endpoints<o:p></o:p></div></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">- the impact on = fragmentation and reassembly is not addressed sufficiently; the = discussion should cite the primary requirements (791, 8200) and go into = a bit more detail.<o:p></o:p></div></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">- IPsec is = clearly sensitive to reordering. Most protocols, TCP included, can adapt = to some level of reordering only up to a limit. Not only are there = limits, but (as noted above) there is a cost at the receiver to support = these capabilities. This doesn=E2=80=99t appear to be = addressed.<o:p></o:p></div></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">- there are MANY = variations to TCP as deployed, as well as other protocols. = Implementations with compromised resources, such as in IoT or low-power = devices, may not all be up to =E2=80=9Cmodern=E2=80=9D = standards.<o:p></o:p></div></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">- there are = protocols that require ordering at L2 (ATM being the primary example); = it is useful to reiterate that this document isn=E2=80=99t recommending = a change that would violate other L2 semantics that depend on = ordering.<o:p></o:p></div></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">AFAICT, the only = clear requirements here are:<o:p></o:p></div></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><blockquote = style=3D"margin-left: 30pt; margin-right: 0in;" type=3D"cite"><div><p = id=3D"section-5-5" style=3D"margin-right: 0in; margin-bottom: 12pt; = margin-left: 0in; caret-color: rgb(34, 34, 34);"><span = style=3D"font-family: "Noto Sans", sans-serif; color: rgb(34, = 34, 34);">Subnetwork implementers SHOULD avoid introducing unnecessary = packet reordering. However, where packet reordering is an unavoidable = consequence of mechanisms that improve overall performance or = reliability (for example, packet striping across multiple links or = link-layer retransmissions), the resulting packet reordering SHOULD = generally be exposed to the receiving endpoint rather than hidden by = subnetwork = resequencing.<o:p></o:p></span></p></div></blockquote><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">RFC3819 says:<o:p></o:p></div></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"border: 1pt = solid windowtext; padding: 0in;"><pre style=3D"margin: 0in; font-size: = 10pt; font-family: "Courier New"; border: medium; padding: = 0in; box-sizing: border-box; font-feature-settings: = var(--default-mono-font-feature-settings,normal); = font-variation-settings: = var(--default-mono-font-variation-settings,normal); text-wrap-mode: = wrap; break-before: page;"><span style=3D"font-size: 12pt;"> = This suggests that subnetwork implementers should try to avoid = packet<o:p></o:p></span></pre><pre style=3D"margin: 0in; font-size: = 10pt; font-family: "Courier New"; border: medium; padding: = 0in;"><span style=3D"font-size: 12pt;"> reordering whenever = possible, but not if doing so compromises<o:p></o:p></span></pre><pre = style=3D"margin: 0in; font-size: 10pt; font-family: "Courier = New"; border: medium; padding: 0in;"><span style=3D"font-size: = 12pt;"> efficiency, impairs reliability, or increases = average packet delay.<o:p></o:p></span></pre></div></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">It isn=E2=80=99t = clear that this document is saying anything different from = RFC3819.<o:p></o:p></div></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">It may be useful = as informational, but as presented it isn=E2=80=99t clear it should be a = BCP; at best, it is an informative update to the context in which = RFC3819 recommendations remain valid.<o:p></o:p></div></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Joe<o:p></o:p></div><div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"><br><br><o:p></o:p></div><blockquote style=3D"margin-top: = 5pt; margin-bottom: 5pt;" type=3D"cite"><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif;">On Jul 7, 2026, at = 9:19<span style=3D"font-family: Arial, sans-serif;">=E2=80=AF</span>AM, = Greg White <<a href=3D"mailto:[email protected]"= style=3D"color: rgb(70, 120, 134); text-decoration: = underline;">[email protected]</a>> = wrote:<o:p></o:p></div></div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;"><o:p> </o:p></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">FYI<br><br>On 7/6/26, 5:25 PM, "<a = href=3D"mailto:[email protected]" style=3D"color: rgb(70, 120, = 134); text-decoration: underline;">[email protected]</a><span = class=3D"Apple-converted-space"> </span><<a = href=3D"mailto:[email protected]" style=3D"color: rgb(70, 120, = 134); text-decoration: = underline;">mailto:[email protected]</a>>" <<a = href=3D"mailto:[email protected]" style=3D"color: rgb(70, 120, = 134); text-decoration: underline;">[email protected]</a><span = class=3D"Apple-converted-space"> </span><<a = href=3D"mailto:[email protected]" style=3D"color: rgb(70, 120, = 134); text-decoration: = underline;">mailto:[email protected]</a>>> = wrote:<br><br><br>A new version of Internet-Draft = draft-white-intarea-reordering-04.txt has been<br>successfully submitted = by Greg White and posted to the<br>IETF repository.<br><br><br>Name: = draft-white-intarea-reordering<br>Revision: 04<br>Title: Proposal for = Updates to Guidance on Packet Reordering<br>Date: 2026-07-06<br>Group: = Individual Submission<br>Pages: 12<br>URL:<span = class=3D"Apple-converted-space"> </span><a = href=3D"https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.= txt" style=3D"color: rgb(70, 120, 134); text-decoration: = underline;">https://www.ietf.org/archive/id/draft-white-intarea-reordering= -04.txt</a><span class=3D"Apple-converted-space"> </span><<a = href=3D"https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.= txt" style=3D"color: rgb(70, 120, 134); text-decoration: = underline;">https://www.ietf.org/archive/id/draft-white-intarea-reordering= -04.txt</a>><br>Status:<span = class=3D"Apple-converted-space"> </span><a = href=3D"https://datatracker.ietf.org/doc/draft-white-intarea-reordering/" = style=3D"color: rgb(70, 120, 134); text-decoration: = underline;">https://datatracker.ietf.org/doc/draft-white-intarea-reorderin= g/</a><span class=3D"Apple-converted-space"> </span><<a = href=3D"https://datatracker.ietf.org/doc/draft-white-intarea-reordering/" = style=3D"color: rgb(70, 120, 134); text-decoration: = underline;">https://datatracker.ietf.org/doc/draft-white-intarea-reorderin= g/</a>><br>HTML:<span class=3D"Apple-converted-space"> </span><a = href=3D"https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.= html" style=3D"color: rgb(70, 120, 134); text-decoration: = underline;">https://www.ietf.org/archive/id/draft-white-intarea-reordering= -04.html</a><span class=3D"Apple-converted-space"> </span><<a = href=3D"https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.= html" style=3D"color: rgb(70, 120, 134); text-decoration: = underline;">https://www.ietf.org/archive/id/draft-white-intarea-reordering= -04.html</a>><br>HTMLized:<span = class=3D"Apple-converted-space"> </span><a = href=3D"https://datatracker.ietf.org/doc/html/draft-white-intarea-reorderi= ng" style=3D"color: rgb(70, 120, 134); text-decoration: = underline;">https://datatracker.ietf.org/doc/html/draft-white-intarea-reor= dering</a><span class=3D"Apple-converted-space"> </span><<a = href=3D"https://datatracker.ietf.org/doc/html/draft-white-intarea-reorderi= ng" style=3D"color: rgb(70, 120, 134); text-decoration: = underline;">https://datatracker.ietf.org/doc/html/draft-white-intarea-reor= dering</a>><br>Diff:<span = class=3D"Apple-converted-space"> </span><a = href=3D"https://author-tools.ietf.org/iddiff?url2=3Ddraft-white-intarea-re= ordering-04" style=3D"color: rgb(70, 120, 134); text-decoration: = underline;">https://author-tools.ietf.org/iddiff?url2=3Ddraft-white-intare= a-reordering-04</a><span = class=3D"Apple-converted-space"> </span><<a = href=3D"https://author-tools.ietf.org/iddiff?url2=3Ddraft-white-intarea-re= ordering-04" style=3D"color: rgb(70, 120, 134); text-decoration: = underline;">https://author-tools.ietf.org/iddiff?url2=3Ddraft-white-intare= a-reordering-04</a>><br><br><br>Abstract:<br><br><br>Several link = technology standards mandate that equipment guarantee<br>in-order = delivery of layer 2 frames, apparently due to a belief that<br>this is = required by higher layer protocols. To meet this requirement<br>they = implement a "resequencing" operation to restore the original<br>packet = order. This can introduce delays that result in net<br>degradation of = performance. Modern TCP and QUIC implementations<br>support features = that significantly improve their tolerance to out-<br>of-order delivery. = This draft is intended to provide new information<br>for layer 2 = technology standards regarding the need to assure in-<br>order delivery = to support IETF protocols.<br><br><br><br><br><br><br>The IETF = Secretariat<br><br><br><br><br><br><br><br>_______________________________= ________________<br>IPsec mailing list --<span = class=3D"Apple-converted-space"> </span><a = href=3D"mailto:[email protected]" style=3D"color: rgb(70, 120, 134); = text-decoration: underline;">[email protected]</a><br>To unsubscribe send = an email to<span class=3D"Apple-converted-space"> </span><a = href=3D"mailto:[email protected]" style=3D"color: rgb(70, 120, 134); = text-decoration: = underline;">[email protected]</a><o:p></o:p></div></div></div></blockqu= ote></div><div style=3D"margin: 0in; font-size: 12pt; font-family: = Aptos, sans-serif;"><o:p> </o:p></div></div></div></div><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; = display: inline = !important;">_______________________________________________</span><br = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration-line: none; = text-decoration-thickness: auto; text-decoration-style: solid;"><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; = display: inline !important;">IPsec mailing list --<span = class=3D"Apple-converted-space"> </span></span><a = href=3D"mailto:[email protected]" style=3D"color: rgb(70, 120, 134); = text-decoration: underline; font-family: Helvetica; font-size: 14px; = font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px;">[email protected]</a><br = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration-line: none; = text-decoration-thickness: auto; text-decoration-style: solid;"><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; = display: inline !important;">To unsubscribe send an email to<span = class=3D"Apple-converted-space"> </span></span><a = href=3D"mailto:[email protected]" style=3D"color: rgb(70, 120, 134); = text-decoration: underline; font-family: Helvetica; font-size: 14px; = font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: = 0px;">[email protected]</a></div></blockquote></div><br></div></body></= html>= --Apple-Mail=_D668AB57-2E1F-48C6-BAD5-7D2146A1B825-- --===============4663714939944771479== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50LWFyZWEg bWFpbGluZyBsaXN0IC0tIGludC1hcmVhQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4g ZW1haWwgdG8gaW50LWFyZWEtbGVhdmVAaWV0Zi5vcmcK --===============4663714939944771479==--