From nobody Wed Mar 24 06:52:32 2021 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244A73A2CCF for ; Wed, 24 Mar 2021 06:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuZgP6D-QtGv for ; Wed, 24 Mar 2021 06:52:26 -0700 (PDT) Received: from sonic317-26.consmr.mail.bf2.yahoo.com (sonic317-26.consmr.mail.bf2.yahoo.com [74.6.129.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17D793A2CCE for ; Wed, 24 Mar 2021 06:52:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1616593943; bh=w5DeZCw5/RVOyqJdWb8L5/m21EOe/kZDdmf3XutN5aE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=DAr3zlTEiNn39C8G+J8hdwHiq93EBhlaoELXAcTl986Vb18hZhvMBQ3QHN5IkGkGw6NzHfWaqNNtBE/GwrSEfsG5vOKtePW35GrkOwffgyYXZGcVs6OQqCaAdcox4eBmUw8MyrfME65HxuuW1iMuPfnKprzHrLZ2gkDOFP2eoiwVfOzrv2kD62PfHSqk3F4IXss813YX6nLI7FY1g0pEWB6JP2tntXmOCrvaMswVKJ8Vph3DD8uePJ/kSnaDhCWHZetWp7xCu3/8h+tYfNr6sz40WnMbegleO0AHL9M/NTgoqGoE5RtyzN/y172DOL/7y++gOix+EfGgmz+iOow/tA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1616593943; bh=Ci0e+J6kYJNS6REMCODlFFyjwTzgAQYIx73GcptZ0Hd=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=t68+XncVPynFSCD8nP+zNi4Z2kfDeQULizLPGe48PjE3tqoFN7mW3ChJPHYY80/g5qFamfinse8moYr4ojHdWzEqhBL9mKDZtd1dZGBYm/VG6HnNf3i6ejJfSBrrlHEJ5KaDnNOvhlxl6TSFJO4IinvphY7ZUBMXJ4QCkoyXY2b6dxTVkaOfkFGUiSabVJjAgNy+dGp96Fa6QvEt8CSFQM+vhw2Sg1v/7HKVVsUHlUB1jjFKxWUWjbfFbWNY68yZDqsj8dx6xTrtgB1PN+/FmFnepL2JYr7Xr5HqMB+eXjfH/Elst1g/D+o3R8RdQrWd5oo9Sc1Fgmr8DvK8lbCaMA== X-YMail-OSG: mRWfVQIVM1mWE0aD2ddUJr30Tp.oQkj.E5I7OnxqKoLkL3V5n4.b5E9Qly5tKR. 4sZBBsVAgaPeZml6sMQ50vy3vqbopkhapyQ1fl78YfH16Swz2jm4FZfySxjLF.8o7RBcEDmNndAL 4jM37ZLbPrJHuTmV66hqR2xLxe7FmDonsmMdqZLDycYVVJs301qsIcv3XuYZKZdnRDaO9rurQwrC i4cYvfhzJc7XWm5BZMZ9cPY5As_FPK_exdfSisT2N7OPXriD5dagr58aU4mUuh3m0xqu8JnCbP83 Cg2b2605WeaOQ5GQ6UZqCMGRVbDZBWrhQRy6HDxCARf4SVDhsXttv6vZldYC5rLJVaPVvkhHRK2i KWKdtFJ5IuYt4SxkC8PvXAbfpG_G87gZs08vL8dKSK7Hwz6o9jIdAeNAAUXZZkiF6lTtOEH.wGHQ QOH_Pg0oaNEZRXf9fy6rPgVHr4YkNHkGZp203VnVhpiRX2F9aGfOuE2C_q8oit8E3nOA8RnxLKDx OoUjcvxpAFjUgQDenctHr3Lb1FB1j9zJxtow982fDm3XQqR_VO_Jd4Rdaw_0c3fet.HGEDbMXfpS 00YyRRsNRiknGTBA3vh1CclUVpafMCQ2aS_EtawS5hJsVDPfb_hFRgLzhEwgeSH7USTe1Eq.taR. iilymmNc.LH6yXFGZ5p6dU1lsE9yPlmZE8X1nHHFj3C4e54kWWDIpdh4hrgSs7kBWGtpLDQrOvaY 9W3pXNTxBrggMnhAquCP5bqTGKLW3YOU.o9rNnhm3rQ7qMqJ1yfiDPddiazCYLtxtT3DuLpLSCbH hcGoh.La90.Ph3T5ntSE8dN3fJmslUQk7hMU_af0aDGPmNtwR0viWWEmdMrq3vTE9z3oGpSTVMRU L7Dp94QqExCGs5jeeEgCtvAJlcqIEIuwKV5vXr3d.IbjxZeCrtwRqiuHeAyNYACJXckZdBn0NYPx fgH1cVpjYyU1IRp5BSVAkyNHoUegzLd9Bx6TZu2EKQOmWC7YyHoEDUDg0QpdCx1D1KDTO0WPSrsY q.uYIaHigBaHEkMILuBjfbQGLY040dh9BzyOuYhlDKqXgnHoptNsfe3AkyLB6sqfUNjbRGDmartg ZRI_hoKyuTIRITdrQwj3e6d90pcl42lm2ytEHaatxOkfPJP5Og573nirfy42jDSXFTW_NUcvJVCO dmObxiQDBWhC0NsLKfUzz76bGn60A1uA.vGEcn8jJS5YwZBtpOKu21OxOxa2tJQ11IZ6fEAnZ_nb otoQNASSIW5mSQasMI_q7vBuwk49ywaGREDWyEBU9q60KzrUVtxF2pVtyjjhIB319b75ObvNCccw UIjixiDAiL0H7PwUGimt0jNrJPo8LrnGWzwzlDKPtKFdT.P6Iimwur3i1JKsadgsCUH27.UbBxcC cEKzu5ytVZfM8ukoYFeajWZK20jPcuUedBKhcGWusDWzLyCH2UsZGnUICQXcldueJ2q3iyFUIeI_ fGKYl9VmTUqkXuzLXIIQ4EsYONoSAeL8wY6AbRZ6Vg5ETbm8wRLgzqEtKwEKF0IdA6DG6ycmRV8. MXb6DJPmRHt3l9TQ5Uz15Y2yOqx3hcMFw8Elqqodg__9Qg50OfNTJGOa8whr4G1qxhc3ixAZmY84 cKAcIMZmd2GTfvAEQ.Npx1MVBBt6Uat.Y0CGQoejvLz7aqhkB_bn3pA5aADfLL6nr8SaH8qlqD5w v50ogFGhYbaq.mWTYj5ABy6x0aZV.5tL2jAGvxxYIKnhLLiUF..QpJK96l6EI68kLGmWcC9CSIYe g4xZBavwNXMnmj7Vho0MVItqqPy7A._6xHCS9Q4_bvMPCpdViM2xPFoWCwWZQp.L.F7BO.QfSgxQ v_b57JnXR4CRmmt_drBkFsAW_sjMrskYQJPmqFRrfQRxKLqhVW3sTZMI_V9Uyr05SWmK.Kh5nTft N5_JfTqZYAav_cBxnqyz57oIGwhybBPe2YwQ8MSJU_HmRjY0mJPC5H1zSQ_G9cwIA8iKRNuaX_4o DvxFiSMP.xVigg3IAJlPxcCRk9THvR3plSEJrffhVI5lGvKDo2TLts02Jbuaamvd6kcJIIJBVUzf Vdf5xOQEPEvZ_NMBlZEzDM67keboEygP5zjRMt2DjsoZCvW6Es2Rv8YGDIKWfFr0EfvBuze8iP.I HC0L6OnKBDWkVMqIRGL4GWJM4Ubd.H0ob.TtUPA86o6HwJo_6zZ8xUe5lrVIW6eZ6FhiZUxxgkHB oLyOqt74RNHLlN9ZCI7479Hg.nnOkiKnE5arABxzi.anEScVvTJ4qSUyktmtZffmVIi9ExYYfiCi PgaU5_QzTD8e32y0vkQBwxdU9qb9f0svcyvY2Cv7q46ci28lh3oBtF_15xET7XAk8pFasVttRwVu tUpHZT4LK9gQiQQpRuG2nv6U5SNOVQwTWwwnAJqkBBU4pAoKYae2Hjs6hETTq0mBU5HOqtMXTRky 59P2sBe7kB7qKm1NjmS.0x0QLMkySLANgbIXU.qyS.q9hMCyuYm0Zx22_F.NQS4a3iOsY1cQVS4l dCaf385Np23eA4ZKir4mNBAmz8N5QegMLb4ljVbpLnEHrGHZzU1NTaDZDVJn95rKYkxf6UPl9iok fJOegrR9uMgKdgpfzXfxEG.ED2p3ZOZoySJwW4OsM1nuHYGY2kdGARXgWF8zPdJRiFsMgxZmh5Gt HxIeEcA8IFipBQLYwKa_nR5W.po7NwgoED5T_N4g8KifP0LP1pRX1SR95umjfHs0dKp4l0RpFGF_ WyPyTjYxwg_Hg0KPc X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Wed, 24 Mar 2021 13:52:23 +0000 Date: Wed, 24 Mar 2021 13:52:23 +0000 (UTC) From: "alex.burr@ealdwulf.org.uk" Reply-To: "alex.burr@ealdwulf.org.uk" To: Martin Duke , Bob Briscoe Cc: "Scheffenegger, Richard" , "Black, David" , TSVWG Message-ID: <560350571.2951543.1616593943423@mail.yahoo.com> In-Reply-To: References: <125328289.3455959.1607381048136.ref@mail.yahoo.com> <125328289.3455959.1607381048136@mail.yahoo.com> <3F562A25-F4F2-4335-9ED7-54299500B8F6@cablelabs.com> <592c7815-126e-fab7-3122-8df71aed9d30@gmx.at> <7bfed921-a5ba-6cbb-cf65-2abf96a86c1d@bobbriscoe.net> <1533769845.1434369.1613388416748@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2951542_1450123864.1616593943417" X-Mailer: WebService/1.1.17936 YMailNorrin Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:86.0) Gecko/20100101 Firefox/86.0 Archived-At: Subject: Re: [tsvwg] L4S and the detection of RFC3168 AQMs X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2021 13:52:31 -0000 ------=_Part_2951542_1450123864.1616593943417 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Bob, Martin, The extra factor of 20 (r) , to account for the possibility that the AQM ma= rks smaller packets with lower probability, makes this approach much slower= if you account for it in a conservative way.However, I don't think we have= to. Suppose that as well as small ECT(0) probe packets, we send an equal n= umber of ECT(1) probe packets of the same size.=20 Then, we wait not to see r * P * 5 marks on all packets, but 6 marks on the= ECT(1) probe packets. If in the same time we see no marks on ECT(0) probe = packets, then (if my calculations are correct, see below) the posterior pro= bability that the is an RFC3168 AQM present is less than 1%. The factor of r is still present, but it now comes from the AQM we are deal= ing with=C2=A0 rather than us having to assume the worst case. If that AQM = applies a lower marking probability to small packets, the method is still s= low, but if such AQMs are rare then this may still be suitable.=20 This is still a bit slower than if we could assume all packet sizes were ma= rked with the same probability (there is a factor of 2 for the ECT(1) probe= packets, plus the waiting time has more variability), but if the AQM is ma= rking all packet sizes the same, then it should be much less than the time = to see 800 marks. Note that since we are assuming that the probability each probe is marked i= s independent, the distance between probes must be random, rather than equa= l as shown in the slides. In principal we should also use the information from the number of marked d= ata packets, but I don't see how to do that immediately. Below is some R code to calculate the posterior probability that an RFC3136= AQM is present. The arguments need to be set differently for the different methods:For the = original method, NumPackets is the total number of packets (probe and data)= , ECT0Ratio is P (8 in your example) and ECT0Marks=C2=A0 and ECT1Marks are the number of observed marks.=20 For the above method, NumPackets is the number of ECT1 plus ECT0 probe pack= ets (not including data packets), and ECT0Ratio is 2 (because there are equ= al number of ECT1 and ECT0 probe packets).=20 When passing ECT0Ratio=3D2, ECT0Marks=3D0 and ECT1Marks=3D6, the posterior = probability always seems to be less than 1% and does not depend much on Num= Packets. Hope this is of interest, Alex =C2=A0=3D=3D=3D=3D=3D=3D=3D=20 library(VGAM) P_3186Present <- function(NumPackets, ECT0Ratio,ECT0Marks, ECT1Marks) { =C2=A0 NumECT0Packets =3D NumPackets/ECT0Ratio =C2=A0 NumECT1Packets =3D NumPackets - NumECT0Packets =C2=A0 likelihood =3D dbetabinom.ab(ECT0Marks,NumECT0Packets,ECT1Marks+1,Nu= mECT1Packets-ECT1Marks+1) =C2=A0 if(ECT0Marks>1){ =C2=A0=C2=A0=C2=A0 likelihood_converse <- 0 =C2=A0 } =C2=A0 else{ =C2=A0=C2=A0=C2=A0 likelihood_converse <- 1 =C2=A0 } =C2=A0 =C2=A0 Prior_RFC3168 <- 0.5 =C2=A0 Prior_NotRFC3168 <- 1 - Prior_RFC3168 =C2=A0 posterior =3D likelihood * Prior_RFC3168/ (Prior_RFC3168 * likelihoo= d + Prior_NotRFC3168 * likelihood_converse) =C2=A0=C2=A0 posterior } On Wednesday, March 10, 2021, 6:20:19 PM GMT, Bob Briscoe wrote: =20 =20 Martin, Alex, In case you missed the pointer in Greg's presentation today, here's the=20 link to the slides I prepared on why I don't think this idea is likely=20 to fly... https://bobbriscoe.net/presents/2103ietf/l4s-exclusive-ecn-marking.pdf TL;DR: Seems too slow for in-band testing (perhaps need 800 CE marks).=20 Useful out-of-band, but we already have good out-of-band tests without it. Pls push back, if you can think of an argument against. Bob On 15/02/2021 11:26, alex.burr@ealdwulf.org.uk wrote: > Martin, Bob, all, > I am happy for these ideas to be taken forward by Bob or anyone else=C2= =A0 - unfortunately I am unlikely to have time to contribute, as I am not w= orking on networking at present.=C2=A0 As such I don't have any opinions on= what is the appropriate doc. > > best, > Alex > > > On Thursday, February 11, 2021, 12:29:45 AM GMT, Bob Briscoe wrote: > > > > > > Martin, > > Greg and I spoke about this very question earlier in the week. > > At minimum, we could write all the details covered in this thread into th= e tech report about Classic ECN AQM Fallback that Asad & I prepared earlier= . "We" might mean Alex or me, or someone else? I would be happy to either A= CK Alex or include him as a co-author - if he was willing. > > I feel that would be more appropriate than an IETF draft at the mo, at le= ast while it's not implemented or tested. Then the IETF drafts (l4sops, ecn= -l4s-id, dualQ, etc.) could give a brief outline of the idea, while referri= ng out for fuller details. > > In that tech report, there is already a section on ideas for the design o= f active tests, which it says have not been implemented or tested. It would= be published on arXiv as a new version, which is suitable as an archival r= ef. > > Then, as Alex suggests, we would need to update the dualQ draft. > As Alex pointed out, not supporting ECT0 can later be reversed (e.g. if t= he L4S experiment later moves to PS), whereas supporting ECT0 from the star= t, them removing it later would miss the opportunity to provide certainty. = This is the part I like most. > > We would also have to not make ECT0 support the default in the reference = Linux implementation of the DualQ. > > > Bob > > > On 10/02/2021 18:37, Martin Duke wrote: > > >>=C2=A0 =C2=A0=20 > Well this all seems very promising! > > > > > Does anyone have the bandwidth to write something down? Should there be a= separate draft that articulates the design? Would this replace the current= Prague approach? > > > > > Martin > > > > > > On Tue, Feb 9, 2021 at 3:09 PM Bob Briscoe wrote: > > >> Richard, >> >> First, thank you for reviving this thread, because it brought Alex's >> last posting (in Dec) to my attention. I'll respond to that separately >> (probably ma=C3=B1ana, as it's getting late). >> >> Pls see inline tagged [BB]... >> >> On 09/02/2021 11:05, Scheffenegger, Richard wrote: >>> Martin, group, >>> >>> >>> AccECN is not tied to RFC3168 (and quite the opposite, it tries to be a= s >>> impartial to the specifics of when/why packets were marked in whichever >>> way). >> [BB] Also, in case people aren't aware: an L4S sender using TCP MUST >> negotiate the use of Accurate ECN TCP feedback with its peer. So I think >> there's no case where a transport would not provide feedback for Alex's >> idea. >> >>> Therefore the Packet-CE counter (you refer to it as PCE, while the draf= t >>> refers to the (full) counter as cep [from CE_packet] is incremented >>> regardless of which packet arrives with the CE mark (control, data, >>> retransmission, ...). >>> >>> Similar for the Byte-CE counter (BCE, in the AccECN draft ceb from >>> CE_bytes). As only TCP payload bytes arriving with the CE mark would be >>> accounted, the behavior as expected in the discussion below is already >>> implicitly available when using AccECN. >> [BB] ...only if the data receiver supports sending the AccECN TCP Option >> (optional) and the new TCP Option traverses the path successfully and >> the data sender supports reading the TCP Option (optional). >> >> Nonetheless, if any of these three is not the case, it might still be >> possible to work out whether a CE marking was on a probe packet... >> >> The ACK that carries the CE packet counter also carries an ACKno (and >> possibly SACK options). When a zero-sized probe is sent, it won't elicit >> an ACK on its own (TCP doesn't ACK pure ACKs). But if the probe is CE >> marked, when the data receiver ACKs subsequent data packet(s), the CE >> packet counter will include any CE marking on the probe. It seems that >> doesn't help, because the data sender cannot tell whether the CE mark >> was on the data packets or the probe. But if the counter ever increases >> by more than the number of data packets covered by the ACK, the probe >> must have been marked as well. >> >> That sounds like having to wait quite a time for the possibility of all >> packets together being marked. But there might be a more deterministic >> way by use the same trick that keep alive probes use... >> >> That is, send a zero-sized probe with SEG.SEQ =3D SND.NXT-1. Being out o= f >> window, each of these probes would immediately elicit a pure ACK from >> the receiver. This might cause problems alongside the other regular >> ACKs, because I think these might look like Dup ACKs (when the trick was >> invented for keepalives, this wasn't a problem 'cos there were no other >> data packets being ACK'd). However, it's possible the sender can work >> out that they are not Dup ACKs, given it knows it sent a probe. >> >> (I'm not totally certain of my facts here - we'd need a TCP expert to >> confirm - Richard?) >> >> >> Bob >> >>> >>> There may be some ambiguity, as AccECN doesn't strictly require an >>> immediate ACK on a CE (only that the next packet after a received CE >>> mark has to convey the changed CE-related counters), but in the general >>> case, AccECN would allow and support such a detection scheme. >> [BB] >> >> >>> Best regards, >>>=C2=A0 =C2=A0=C2=A0 Richard >>> >>> >>> >>> Am 12.12.2020 um 00:22 schrieb Martin Duke: >>>> Excellent, thank you for the reminder. So the L4S sender could >>>> interleave some ECT(0) marked pure ACKs (or retransmissions of the las= t >>>> acknowledged byte) and hope that the PCE counter increases without >>>> corresponding increases in BCE. >>>> >>>> The AccECN spec might need to be updated to specify that these should = be >>>> reported in PCE even though they are not 3168 compliant. >>>> >>>> Scheduling these probes might not exactly be trivial, but if they are >>>> temporally correlated with ECT(1)->CE marks, this would be highly >>>> suggestive, yes? >>>> >>>> On Fri, Dec 11, 2020 at 3:03 PM Black, David >>> > wrote: >>>> >>>>=C2=A0 =C2=A0=C2=A0=C2=A0 In which case, RFC 8311 Section 4.3 allows ex= perimental usage of ECN >>>>=C2=A0 =C2=A0=C2=A0=C2=A0 with such packets (https://tools.ietf.org/htm= l/rfc8311#section-4.3 >>>> ).____ >>>> >>>>=C2=A0 =C2=A0=C2=A0=C2=A0 __ __ >>>> >>>>=C2=A0 =C2=A0=C2=A0=C2=A0 Thanks, --David____ >>>> >>>>=C2=A0 =C2=A0=C2=A0=C2=A0 __ __ >>>> >>>>=C2=A0 =C2=A0=C2=A0=C2=A0 [EXTERNAL EMAIL] ____ >>>> >>>>=C2=A0 =C2=A0=C2=A0=C2=A0 My understanding of 3168 is that only in-wind= ow data packets are >>>>=C2=A0 =C2=A0=C2=A0=C2=A0 marked ECT(0). A zero-length segment is a equ= ivalent to a pure ACK, >>>>=C2=A0 =C2=A0=C2=A0=C2=A0 which is not marked.____ >>>> >>>>=C2=A0 =C2=A0=C2=A0=C2=A0 __ __ >>>> >>>>=C2=A0 =C2=A0=C2=A0=C2=A0 On Fri, Dec 11, 2020 at 12:09 PM C. M. Heard = >>>=C2=A0 =C2=A0=C2=A0=C2=A0 > wrote:____ >>>> >>>>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 On Fri, Dec 11, 2020 = at 11:51 AM Martin Duke >>>>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >>>>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 wrote:____ >>>> >>>>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 This falls under the "much easier to do in other transports" >>>>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 category, where I could just send a PING or HEARTBEAT marked >>>>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 ECT(0) to test the queue in mid-connection, without >>>>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 affecting the latency of anything that matters. But in the >>>>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 TCP case, I'm not sure how to resolve Bob's second objection >>>>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 (running ECT(0) for a long time would be unacceptable).____ >>>> >>>>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 __ __ >>>> >>>>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Could zero-length TCP= segments be used instead of PING or >>>>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 HEARTBEAT? ____ >>>> >>>>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ____ >>>> >>>>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Mike Heard ____ >>>> >> --=20 >> ________________________________________________________________ >> Bob Briscoe=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://bobbriscoe.net/ >> >> >> > --=20 ________________________________________________________________ Bob Briscoe=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://bobbriscoe.net/ =20 ------=_Part_2951542_1450123864.1616593943417 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Bob, Martin,


The extra factor of 20 (r) , to account for the possibility that= the AQM marks smaller packets with lower probability, makes this approach = much slower if you account for it in a conservative way.
However, I don't think we have to. Suppose that a= s well as small ECT(0) probe packets, we send an equal number of ECT(1) pro= be packets of the same size.
Then, we wait not to see r * P * 5 marks on all packets, but 6 marks on = the ECT(1) probe packets. If in the same time we see no marks on ECT(0) pro= be packets, then (if my calculations are correct, see below) the posterior = probability that the is an RFC3168 AQM present is less than 1%.

The factor of r is still present, but it now comes from the AQM we a= re dealing with  rather than us having to assume the worst case. If th= at AQM applies a lower marking probability to small packets, the method is = still slow, but if such AQMs are rare then this may still be suitable.
=
This is still a bit slower tha= n if we could assume all packet sizes were marked with the same probability= (there is a factor of 2 for the ECT(1) probe packets, plus the waiting tim= e has more variability), but if the AQM is marking all packet sizes the sam= e, then it should be much less than the time to see 800 marks.

Note that since we are assuming that the probability each probe = is marked is independent, the distance between probes must be random, rathe= r than equal as shown in the slides.

In principal we= should also use the information from the number of marked data packets, bu= t I don't see how to do that immediately.

Below is so= me R code to calculate the posterior probability that an RFC3136 AQM is pre= sent.

The arguments need to be set differently for th= e different methods:
For the or= iginal method, NumPackets is the total number of packets (probe and d= ata), ECT0Ratio is P (8 in your example) and ECT0Marks  an= d ECT1Marks
are the number of observed marks.
For the above method, NumPackets is the number of ECT1 plus ECT0 probe packets (not including dat= a packets), and ECT0Ratio is 2 (because there are equal number of ECT= 1 and ECT0 probe packets).

When passing ECT0Ratio=3D2, ECT0Marks=3D0 and ECT1Marks=3D6, the p= osterior probability always seems to be less than 1% and does not depend mu= ch on NumPackets.

Hope this is of interest,
=

<= /span>
Alex


<= /span>


 =3D=3D=3D=3D=3D=3D=3D

library(VGAM)

P_3186Present <- function(NumPackets, ECT= 0Ratio,ECT0Marks, ECT1Marks) {

  NumECT0Packets =3D NumPackets/= ECT0Ratio
  NumECT1Packets =3D NumPackets - NumECT0Packets

<= br>  likelihood =3D dbetabinom.ab(ECT0Marks,NumECT0Packets,ECT1Marks+1= ,NumECT1Packets-ECT1Marks+1)

  if(ECT0Marks>1){
 &nb= sp;  likelihood_converse <- 0
  }
  else{
 =    likelihood_converse <- 1
  }

 

&= nbsp; Prior_RFC3168 <- 0.5
  Prior_NotRFC3168 <- 1 - Prior_RF= C3168

  posterior =3D likelihood * Prior_RFC3168/ (Prior_RFC316= 8 * likelihood + Prior_NotRFC3168 * likelihood_converse)

  = ; posterior

}



=20
=20
On Wednesday, March 10, 2021, 6:20:19 PM GMT, Bob Brisc= oe <ietf@bobbriscoe.net> wrote:


Martin, Alex,

In case you missed the pointer in Greg's presentation today, = here's the
link to the slides I prepared on why I don't = think this idea is likely
to fly...
https://bobbriscoe.= net/presents/2103ietf/l4s-exclusive-ecn-marking.pdf
<= br clear=3D"none">TL;DR: Seems too slow for in-band testing (perhaps need 8= 00 CE marks).
Useful out-of-band, but we already have go= od out-of-band tests without it.

Pls p= ush back, if you can think of an argument against.


Bob

On 15/02= /2021 11:26, alex.burr@ealdwulf.org.uk wrote:
> Martin, Bob, all,
> I am happy for t= hese ideas to be taken forward by Bob or anyone else  - unfortunately = I am unlikely to have time to contribute, as I am not working on networking= at present.  As such I don't have any opinions on what is the appropr= iate doc.
>
> best,
> Alex
>
>
> On Thursday, February 11, 2021, 12:29:45 AM GMT, Bob Briscoe <<= a shape=3D"rect" href=3D"mailto:ietf@bobbriscoe.net" rel=3D"nofollow" targe= t=3D"_blank">ietf@bobbriscoe.net> wrote:
>
>
>
>
>
> Martin,
>
> Greg and I spoke about this very question earlier in the w= eek.
>
> At minimum, we could wri= te all the details covered in this thread into the tech report about Classi= c ECN AQM Fallback that Asad & I prepared earlier. "We" might mean Alex= or me, or someone else? I would be happy to either ACK Alex or include him= as a co-author - if he was willing.
>
> I feel that would be more appropriate than an IETF draft at the mo,= at least while it's not implemented or tested. Then the IETF drafts (l4sop= s, ecn-l4s-id, dualQ, etc.) could give a brief outline of the idea, while r= eferring out for fuller details.
>
&= gt; In that tech report, there is already a section on ideas for the design= of active tests, which it says have not been implemented or tested. It wou= ld be published on arXiv as a new version, which is suitable as an archival= ref.
>
> Then, as Alex suggests,= we would need to update the dualQ draft.
> As Alex po= inted out, not supporting ECT0 can later be reversed (e.g. if the L4S exper= iment later moves to PS), whereas supporting ECT0 from the start, them remo= ving it later would miss the opportunity to provide certainty. This is the = part I like most.
>
> We would al= so have to not make ECT0 support the default in the reference Linux impleme= ntation of the DualQ.
>
>
> Bob
>
>
> On 10/02/2021 18:37, Martin Duke wrote:
&g= t;
>
>>   
> Well this all seems very promising!
>>
>
>
> Does anyone have the bandwidth to write something down? Sho= uld there be a separate draft that articulates the design? Would this repla= ce the current Prague approach?
>
&g= t;
>
>
> Mar= tin
>
>
>>
>
> On Tue, = Feb 9, 2021 at 3:09 PM Bob Briscoe <in@bobbriscoe.net>= ; wrote:
>
>
&g= t;> Richard,
>>
>> First= , thank you for reviving this thread, because it brought Alex's
>> last posting (in Dec) to my attention. I'll respond to that= separately
>> (probably ma=C3=B1ana, as it's getti= ng late).
>>
>> Pls see inl= ine tagged [BB]...
>>
>> On= 09/02/2021 11:05, Scheffenegger, Richard wrote:
>>= > Martin, group,
>>>
>&g= t;>
>>> AccECN is not tied to RFC3168 (and qu= ite the opposite, it tries to be as
>>> impartia= l to the specifics of when/why packets were marked in whichever
>>> way).
>> [BB] Also, in case peo= ple aren't aware: an L4S sender using TCP MUST
>> n= egotiate the use of Accurate ECN TCP feedback with its peer. So I think
>> there's no case where a transport would not provide= feedback for Alex's
>> idea.
>= ;>
>>> Therefore the Packet-CE counter (you r= efer to it as PCE, while the draft
>>> refers to= the (full) counter as cep [from CE_packet] is incremented
>>> regardless of which packet arrives with the CE mark (control= , data,
>>> retransmission, ...).
>>>
>>> Similar for the Byte-CE cou= nter (BCE, in the AccECN draft ceb from
>>> CE_b= ytes). As only TCP payload bytes arriving with the CE mark would be
>>> accounted, the behavior as expected in the discussi= on below is already
>>> implicitly available whe= n using AccECN.
>> [BB] ...only if the data receive= r supports sending the AccECN TCP Option
>> (option= al) and the new TCP Option traverses the path successfully and
>> the data sender supports reading the TCP Option (optional).<= br clear=3D"none">>>
>> Nonetheless, if any o= f these three is not the case, it might still be
>>= possible to work out whether a CE marking was on a probe packet...
>>
>> The ACK that carries the CE = packet counter also carries an ACKno (and
>> possib= ly SACK options). When a zero-sized probe is sent, it won't elicit
>> an ACK on its own (TCP doesn't ACK pure ACKs). But if th= e probe is CE
>> marked, when the data receiver ACK= s subsequent data packet(s), the CE
>> packet count= er will include any CE marking on the probe. It seems that
>> doesn't help, because the data sender cannot tell whether the CE= mark
>> was on the data packets or the probe. But = if the counter ever increases
>> by more than the n= umber of data packets covered by the ACK, the probe
>&= gt; must have been marked as well.
>>
>> That sounds like having to wait quite a time for the possibil= ity of all
>> packets together being marked. But th= ere might be a more deterministic
>> way by use the= same trick that keep alive probes use...
>>
>> That is, send a zero-sized probe with SEG.SEQ =3D SND.= NXT-1. Being out of
>> window, each of these probes= would immediately elicit a pure ACK from
>> the re= ceiver. This might cause problems alongside the other regular
>> ACKs, because I think these might look like Dup ACKs (when th= e trick was
>> invented for keepalives, this wasn't= a problem 'cos there were no other
>> data packets= being ACK'd). However, it's possible the sender can work
>> out that they are not Dup ACKs, given it knows it sent a probe.>>
>> (I'm not totally certa= in of my facts here - we'd need a TCP expert to
>> = confirm - Richard?)
>>
>>>> Bob
>>
= >>>
>>> There may be some ambiguity, as= AccECN doesn't strictly require an
>>> immediat= e ACK on a CE (only that the next packet after a received CE
>>> mark has to convey the changed CE-related counters), but i= n the general
>>> case, AccECN would allow and s= upport such a detection scheme.
>> [BB]
>>
>>
>>> B= est regards,
>>>     Richard
>>>
>>>
>>>
>>> Am 12.12.2020 um 00:22 schrieb= Martin Duke:
>>>> Excellent, thank you for t= he reminder. So the L4S sender could
>>>> int= erleave some ECT(0) marked pure ACKs (or retransmissions of the last
>>>> acknowledged byte) and hope that the PCE count= er increases without
>>>> corresponding incre= ases in BCE.
>>>>
>>&= gt;> The AccECN spec might need to be updated to specify that these shou= ld be
>>>> reported in PCE even though they a= re not 3168 compliant.
>>>>
>>>> Scheduling these probes might not exactly be trivial, but= if they are
>>>> temporally correlated with = ECT(1)->CE marks, this would be highly
>>>>= ; suggestive, yes?
>>>>
>= ;>>> On Fri, Dec 11, 2020 at 3:03 PM Black, David <David.Black@dell.com
>>>> <mailto:<= a shape=3D"rect" href=3D"mailto:David.Black@dell.com" rel=3D"nofollow" targ= et=3D"_blank">David.Black@dell.com>> wrote:
>= ;>>>
>>>>      I= n which case, RFC 8311 Section 4.3 allows experimental usage of ECN
>>>>      with such packets (https://tools.ietf.org/html/rfc8311#section= -4.3
>>>> <https://tools.ietf.org/html/rfc8311#section-4.3>).____
>>>>
>>>>  &nbs= p;   __ __
>>>>
&= gt;>>>      Thanks, --David____
>>>>
>>>>    &= nbsp; __ __
>>>>
>>&g= t;>      [EXTERNAL EMAIL] ____
>= ;>>>
>>>>      M= y understanding of 3168 is that only in-window data packets are
>>>>      marked ECT(0). A zero-leng= th segment is a equivalent to a pure ACK,
>>>>= ;      which is not marked.____
>&= gt;>>
>>>>      __ = __
>>>>
>>>>&nb= sp;     On Fri, Dec 11, 2020 at 12:09 PM C. M. Heard <heard@pobox.com
>>>>   &= nbsp;  <mailto:heard@pobox.com>> wrote:____
>>>>
>>>>  &n= bsp;       On Fri, Dec 11, 2020 at 11:51 AM M= artin Duke
>>>>      = ;    <martin.h.duke@gmail.com <m= ailto:martin.h.duke@gmail.com>>
>>>>          wrote:= ____
>>>>
>>>>&= nbsp;             Th= is falls under the "much easier to do in other transports"
>>>>          &n= bsp;   category, where I could just send a PING or HEARTBEAT mark= ed
>>>>       &= nbsp;      ECT(0) to test the queue in mid-connect= ion, without
>>>>     &nb= sp;        affecting the latency of anyt= hing that matters. But in the
>>>>  &nbs= p;           TCP case, I'= m not sure how to resolve Bob's second objection
>>= >>            =   (running ECT(0) for a long time would be unacceptable).____
>>>>
>>>>   &= nbsp;      __ __
>>>>= ;
>>>>       &n= bsp;  Could zero-length TCP segments be used instead of PING or
>>>>        &nbs= p; HEARTBEAT? ____
>>>>
>= ;>>>          ____
>>>>
>>>>   =        Mike Heard ____
>= >>>
>> --
>> ____= ____________________________________________________________
>> Bob Briscoe              &n= bsp;                http:= //bobbriscoe.net/
>>
>>=
>>
>

--
________________________________________= ________________________
Bob Briscoe      =                      = ;   http://bobbriscoe.net/

------=_Part_2951542_1450123864.1616593943417--