[Int-area] Re: [IPsec] New Version Notification for draf t-white-intarea-reordering-04.txt

--===============6284836073218924159==
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_D96F3713-7612-41F4-A457-0D99455ADB78"


--Apple-Mail=_D96F3713-7612-41F4-A457-0D99455ADB78
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi, all,

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.

Additionally, it omits key information as to why layer 2 frame ordering =
is maintained in certain protocols.

In particular:
- the abstract describes that reordering =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 reordering occurs and the =
receiver reorders anyway (as with TCP). The lack of such reordering can =
also increase work at the receiver, as when TCP sends SACK rather than =
cumulative ACK. I.e., the impact is not always clear.

- on-path interpretation of TCP streams, including DPI, don=E2=80=99t =
always react as well as modern TCP endpoints

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

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

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

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

AFAICT, the only clear requirements here are:

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.

RFC3819 says:

   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.

It isn=E2=80=99t clear that this document is saying anything different =
from RFC3819.

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.

Joe

> On Jul 7, 2026, at 9:19=E2=80=AFAM, Greg White =
<[email protected]> wrote:
>=20
> FYI
>=20
> =EF=BB=BFOn 7/6/26, 5:25 PM, "[email protected] =
<mailto:[email protected]>" <[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]
> To unsubscribe send an email to [email protected]


--Apple-Mail=_D96F3713-7612-41F4-A457-0D99455ADB78
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;">Hi, all,<div><br></div><div>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.</div><div><br></div><div>Additionally, it omits =
key information as to why layer 2 frame ordering is maintained in =
certain protocols.</div><div><br></div><div>In particular:</div><div>- =
the abstract describes that reordering =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 reordering occurs and the =
receiver reorders anyway (as with TCP). The lack of such reordering can =
also increase work at the receiver, as when TCP sends SACK rather than =
cumulative ACK. I.e., the impact is not always =
clear.</div><div><br></div><div>- on-path interpretation of TCP streams, =
including DPI, don=E2=80=99t always react as well as modern TCP =
endpoints</div><div><br></div><div>- 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.</div><div><br></div><div>- 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.</div><div><br></div><div>- =
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.</div><div><br></div><div>- 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.</div><div><br></div><div>AFAICT, the only clear requirements =
here are:</div><div><br></div><blockquote style=3D"margin: 0 0 0 40px; =
border: none; padding: 0px;"><div><p id=3D"section-5-5" style=3D"padding: =
0px; margin: 0px 0px 1em; caret-color: rgb(34, 34, 34); color: rgb(34, =
34, 34); font-family: &quot;Noto Sans&quot;, Arial, Helvetica, =
sans-serif;">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.</p></div></blockquote><div>RFC3819 =
says:</div><div><br></div><div><pre class=3D"newpage" style=3D"font-size: =
16px; box-sizing: border-box; border: 0px solid; margin: 0px; padding: =
0px; font-family: =
var(--default-mono-font-family,ui-monospace,SFMono-Regular,Menlo,Monaco,Co=
nsolas,&quot;Liberation Mono&quot;,&quot;Courier New&quot;,monospace); =
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;">   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.</pre></div><div><br></div><div>It isn=E2=80=99t clear that this =
document is saying anything different from =
RFC3819.</div><div><br></div><div>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.</div><div><br></div><div>Joe<br><div><div><br><blockquote =
type=3D"cite"><div>On Jul 7, 2026, at 9:19=E2=80=AFAM, Greg White =
&lt;[email protected]&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div><div>FYI<br><br>=EF=BB=BFOn =
7/6/26, 5:25 PM, "[email protected] =
&lt;mailto:[email protected]&gt;" &lt;[email protected] =
&lt;mailto:[email protected]&gt;&gt; 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: =
https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.txt =
&lt;https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.txt&=
gt;<br>Status: =
https://datatracker.ietf.org/doc/draft-white-intarea-reordering/ =
&lt;https://datatracker.ietf.org/doc/draft-white-intarea-reordering/&gt;<b=
r>HTML: =
https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.html =
&lt;https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.html=
&gt;<br>HTMLized: =
https://datatracker.ietf.org/doc/html/draft-white-intarea-reordering =
&lt;https://datatracker.ietf.org/doc/html/draft-white-intarea-reordering&g=
t;<br>Diff: =
https://author-tools.ietf.org/iddiff?url2=3Ddraft-white-intarea-reordering=
-04 =
&lt;https://author-tools.ietf.org/iddiff?url2=3Ddraft-white-intarea-reorde=
ring-04&gt;<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 -- [email protected]<br>To =
unsubscribe send an email to =
[email protected]<br></div></div></blockquote></div><br></div></div></b=
ody></html>=

--Apple-Mail=_D96F3713-7612-41F4-A457-0D99455ADB78--


--===============6284836073218924159==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50LWFyZWEg
bWFpbGluZyBsaXN0IC0tIGludC1hcmVhQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4g
ZW1haWwgdG8gaW50LWFyZWEtbGVhdmVAaWV0Zi5vcmcK

--===============6284836073218924159==--