[ippm] Re: STAMP extension to enable bi-directional ECN meas urement

<[email protected]> Tue, 18 Mar 2025 14:10:20 +0000
Newsgroups gmane.ietf.ippm,gmane.ietf.tsvwg
Message-ID <BEZP281MB2007FB6A0090B646E1D0DC469CDE2@BEZP281MB2007.DEUP281.PROD.OUTLOOK.COM>
--===============0694891122920174359==
Content-Language: de-DE
Content-Type: multipart/alternative;
	boundary="_000_BEZP281MB2007FB6A0090B646E1D0DC469CDE2BEZP281MB2007DEUP_"

--_000_BEZP281MB2007FB6A0090B646E1D0DC469CDE2BEZP281MB2007DEUP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Greg,

thanks, the draft addresses a reasonable goal, detecting transparent transp=
ort of ECN codepoints along a network path. This is useful, independently o=
f the question whether you try to detect changes RFC3168  or RFC9331 ECN bi=
t settings. I note, that we had to debug our lab L4S set up, and we had to =
debug our L4S production chain, as ECN codepoints didn't pass transparently=
 end-to-end, and I think to recollect that Comcast did so too. To quote fro=
m Jason's draft,

https://www.ietf.org/archive/id/draft-livingood-low-latency-deployment-07.h=
tml: "Nevertheless, it is important to check network policies and router co=
nfigurations to confirm [transparent transport of ECN codepoints] and to va=
lidate it via packet captures at an end user CPE."

One could of course use a STAMP implementation to test, whether a, say,  EC=
N-aware scheduler changes ECT to CE too. This requires to load the link whe=
re that scheduler operates  -  STAMP is adding features to that extent. UDP=
 Speed Test (UDPST) may be an option too.

I think, operational and security concerns shouldn't be ignored (I take the=
 generalized point "source shouldn't send ECN codepoints, if ECN no ECN awa=
re transport is supported" as such a concern). If STAMP offers a sufficient=
 set of features and implementation requirements, like authentication of a =
STAMP test packet sender and limiting replies/reflection of test packets to=
 the authenticated STAMP sender. If I recollect correctly, STAMP offers all=
 that (Greg Mirsky can confirm this, he knows best).

Regards,

Ruediger


Von: Greg White <g.white=3D40CableLabs.com-Tr9gZwTxerDR74oF6e/[email protected]>
Gesendet: Dienstag, 18. M=E4rz 2025 12:46
An: [email protected]
Cc: [email protected]
Betreff: [tsvwg] STAMP extension to enable bi-directional ECN measurement

Hi all,

I'd like to make TSVWG aware of a draft in IPPM that defines an extension t=
o the Simple Two-Way Active Measurement Protocol (STAMP).  STAMP supports "=
extensions" in the form of TLVs that can optionally be included in a STAMP =
test packet by a Session Sender, and that are returned in the reflected pac=
ket by the Session Reflector (often with additional information inserted).

This new extension allows STAMP to be used for bi-directional measurement o=
f path ECN characteristics, including ECN traversal/bleaching measurements,=
 probing for CE-marking on paths, and differential measurement of path char=
acteristics that depend on the value of the ECN field.  STAMP previously ha=
d the ability to be used to test bi-directional DSCP characteristics of a p=
ath, but only outbound ECN characteristics.

This draft was presented during the IPPM session today, and it was suggeste=
d that TSVWG be made aware since it has to do with ECN marking, and by send=
ing test packets with various ECN values, it could be seen as violating the=
 letter of RFC3168  & RFC9331 (e.g. having a host send individual ECT1 test=
 packets, even though it doesn't implement the Prague requirements).

Time permitting, I could give a brief overview during the TSVWG tomorrow, b=
ut the draft itself is pretty straightforward.  The important point from th=
e IPPM perspective is to seek consensus from TSVWG that it's ok to use STAM=
P to measure path ECN characteristics in this way.

https://datatracker.ietf.org/meeting/122/materials/slides-122-ippm-stamp-ex=
tension-for-dscp-and-ecn-traversal-measurement-00
https://gwhitecl.github.io/draft-white-ippm-stamp-ecn/draft-white-ippm-stam=
p-ecn.html

Best,
Greg



--_000_BEZP281MB2007FB6A0090B646E1D0DC469CDE2BEZP281MB2007DEUP_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Aptos;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	font-size:12.0pt;
	font-family:"Aptos",sans-serif;
	mso-ligatures:standardcontextual;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#467886;
	text-decoration:underline;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;
	mso-ligatures:none;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"DE" link=3D"#467886" vlink=3D"#96607D" style=3D"word-wrap:bre=
ak-word">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;mso-fareast-language=
:EN-US">Hi Greg,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;mso-fareast-language=
:EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f=
areast-language:EN-US">thanks, the draft addresses a reasonable goal, detec=
ting transparent transport of ECN codepoints along a network path. This is =
useful, independently of the question
 whether you try to detect changes </span><span lang=3D"EN-US" style=3D"fon=
t-size:11.0pt">RFC3168 &nbsp;or RFC9331 ECN bit settings. I note, that we h=
ad to debug our lab L4S set up, and we had to debug our L4S production chai=
n, as ECN codepoints didn&#8217;t pass transparently
 end-to-end, and I think to recollect that Comcast did so too. To quote fro=
m Jason&#8217;s draft,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt"><o:p=
>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f=
areast-language:EN-US"><a href=3D"https://www.ietf.org/archive/id/draft-liv=
ingood-low-latency-deployment-07.html">https://www.ietf.org/archive/id/draf=
t-livingood-low-latency-deployment-07.html</a><span style=3D"color:black">:
 &#8220;Nevertheless, it is important to check network policies and router =
configurations to confirm [transparent transport of ECN codepoints] and to =
validate it via packet captures at an end user CPE.&#8221;<o:p></o:p></span=
></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;color=
:black;mso-fareast-language:EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;color=
:black;mso-fareast-language:EN-US">One could of course use a STAMP implemen=
tation to test, whether a, say, &nbsp;ECN-aware scheduler changes ECT to CE=
 too. This requires to load the link where
 that scheduler operates &nbsp;&#8211; &nbsp;STAMP is adding features to th=
at extent. UDP Speed Test (UDPST) may be an option too.</span><span lang=3D=
"EN-US" style=3D"font-size:11.0pt;mso-fareast-language:EN-US"><o:p></o:p></=
span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f=
areast-language:EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f=
areast-language:EN-US">I think, operational and security concerns shouldn&#=
8217;t be ignored (I take the generalized point &#8220;source shouldn&#8217=
;t send ECN codepoints, if ECN no ECN aware transport is
 supported&#8221; as such a concern). If STAMP offers a sufficient set of f=
eatures and implementation requirements, like authentication of a STAMP tes=
t packet sender and limiting replies/reflection of test packets to the auth=
enticated STAMP sender. If I recollect
 correctly, STAMP offers all that (Greg Mirsky can confirm this, he knows b=
est). <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f=
areast-language:EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f=
areast-language:EN-US">Regards,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f=
areast-language:EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f=
areast-language:EN-US">Ruediger<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f=
areast-language:EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"mso-fareast-language:E=
N-US"><o:p>&nbsp;</o:p></span></p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,sans-serif;mso-ligatures:none">Von:</span></b><span style=3D=
"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif;mso-ligatures:=
none"> Greg White &lt;g.white=3D40CableLabs.com-Tr9gZwTxerDR74oF6e/[email protected]&gt;
<br>
<b>Gesendet:</b> Dienstag, 18. M=E4rz 2025 12:46<br>
<b>An:</b> [email protected]<br>
<b>Cc:</b> [email protected]<br>
<b>Betreff:</b> [tsvwg] STAMP extension to enable bi-directional ECN measur=
ement<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">Hi a=
ll,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt"><o:p=
>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">I&#8=
217;d like to make TSVWG aware of a draft in IPPM that defines an extension=
 to the Simple Two-Way Active Measurement Protocol (STAMP).&nbsp; STAMP sup=
ports &#8220;extensions&#8221; in the form of TLVs that can optionally
 be included in a STAMP test packet by a Session Sender, and that are retur=
ned in the reflected packet by the Session Reflector (often with additional=
 information inserted).<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt"><o:p=
>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">This=
 new extension allows STAMP to be used for bi-directional measurement of pa=
th ECN characteristics, including ECN traversal/bleaching measurements, pro=
bing for CE-marking on paths, and differential
 measurement of path characteristics that depend on the value of the ECN fi=
eld.&nbsp; STAMP previously had the ability to be used to test bi-direction=
al DSCP characteristics of a path, but only outbound ECN characteristics.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt"><o:p=
>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">This=
 draft was presented during the IPPM session today, and it was suggested th=
at TSVWG be made aware since it has to do with ECN marking, and by sending =
test packets with various ECN values,
 it could be seen as violating the letter of RFC3168 &nbsp;&amp; RFC9331 (e=
.g. having a host send individual ECT1 test packets, even though it doesn&#=
8217;t implement the Prague requirements).<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt"><o:p=
>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">Time=
 permitting, I could give a brief overview during the TSVWG tomorrow, but t=
he draft itself is pretty straightforward.&nbsp; The important point from t=
he IPPM perspective is to seek consensus from
 TSVWG that it&#8217;s ok to use STAMP to measure path ECN characteristics =
in this way.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt"><o:p=
>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt"><a h=
ref=3D"https://datatracker.ietf.org/meeting/122/materials/slides-122-ippm-s=
tamp-extension-for-dscp-and-ecn-traversal-measurement-00">https://datatrack=
er.ietf.org/meeting/122/materials/slides-122-ippm-stamp-extension-for-dscp-=
and-ecn-traversal-measurement-00</a><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt"><a h=
ref=3D"https://gwhitecl.github.io/draft-white-ippm-stamp-ecn/draft-white-ip=
pm-stamp-ecn.html">https://gwhitecl.github.io/draft-white-ippm-stamp-ecn/dr=
aft-white-ippm-stamp-ecn.html</a><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt"><o:p=
>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">Best=
,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">Greg=
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt"><o:p=
>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt"><o:p=
>&nbsp;</o:p></span></p>
</div>
</body>
</html>

--_000_BEZP281MB2007FB6A0090B646E1D0DC469CDE2BEZP281MB2007DEUP_--


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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KaXBwbSBtYWls
aW5nIGxpc3QgLS0gaXBwbUBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv
IGlwcG0tbGVhdmVAaWV0Zi5vcmcK

--===============0694891122920174359==--