Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Wed, 20 March 2019 19:39 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
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 A174E129508 for <tsvwg@ietfa.amsl.com>; Wed, 20 Mar 2019 12:39:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001] autolearn=ham autolearn_force=no
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 IJxOj6AwhBsg for <tsvwg@ietfa.amsl.com>; Wed, 20 Mar 2019 12:39:26 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 33EA6130FC7 for <tsvwg@ietf.org>; Wed, 20 Mar 2019 12:39:22 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 45FAF1B00082; Wed, 20 Mar 2019 19:39:14 +0000 (GMT)
Message-ID: <5C9296E1.4010703@erg.abdn.ac.uk>
Date: Wed, 20 Mar 2019 19:39:13 +0000
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Holland, Jake" <jholland@akamai.com>
CC: Bob Briscoe <ietf@bobbriscoe.net>, "David P. Reed" <dpreed@deepplum.com>, Vint Cerf <vint@google.com>, tsvwg IETF list <tsvwg@ietf.org>, bloat <bloat@lists.bufferbloat.net>
References: <d91a6a71-5898-9571-2a02-0d9d83839615@bobbriscoe.net> <CAA93jw5MTdn9EQgpZ0xrjqEi7UKqH3H_741anoB+pa0dtD=fpA@mail.gmail.com> <1E80578D-A589-4CA0-9015-B03B63042355@gmx.de> <CAA93jw7jvjbZkEgO8xc03uCayo+o-uENxxAkzQOaz_EZSLhocw@mail.gmail.com> <27FA673A-2C4C-4652-943F-33FAA1CF1E83@gmx.de> <1552669283.555112988@apps.rackspace.com> <alpine.DEB.2.20.1903151915320.3161@uplift.swm.pp.se> <7029DA80-8B83-4775-8261-A4ADD2CF34C7@akamai.com> <CAHxHggfPCqf9biCDmHMqA38=4y6gY6pFtRVMjMrrzYfLyRBf-g@mail.gmail.com> <1552846034.909628287@apps.rackspace.com> <5458c216-07b9-5b06-a381-326de49b53e0@bobbriscoe.net> <AC14ACBB-A7CC-40E0-882C-2519D05ADC05@akamai.com>
In-Reply-To: <AC14ACBB-A7CC-40E0-882C-2519D05ADC05@akamai.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/LdOLTbhysKhnyAJZLL2lmoBQEU8>
Subject: Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2019 19:39:31 -0000
See below On 20/03/2019, 19:04, Holland, Jake wrote: > > Hi Bob & Greg, > > I agree there has been a reasonably open conversation about the L4S > > work, and thanks for all your efforts to make it so. > > However, I think there's 2 senses in which "private" might be fair that > > I didn't see covered in your rebuttals (merging forks and including > > Greg's rebuttal by reference from here: > > https://lists.bufferbloat.net/pipermail/bloat/2019-March/009038.html ) > > Please note: > > I don't consider these senses of "private" a disqualifying argument > > against the use of L4S, though I do consider them costs that should be > > taken into account (and of course opinions may differ here). > > With that said, I wondered whether either of you have any responses that > > speak to these points: > > 1. the L4S use of the ECT(1) codepoint can't be marked CE except by a > > patent-protected AQM scheduler. > > I understand that l4s-id suggests the possibility of an alternate > > scheme. However, comparing the MUSTs of the section 5 requirements > > with the claims made by the patent seems to leave no room for an > > alternate that would not infringe the patent claims, unless I'm missing > > something? > > https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-06#section-5 > > https://patents.google.com/patent/US20170019343A1/en > > 2. the L4S use of the ECT(1) codepoint privileges the low latency use > > case. > > As Jonathan Morton pointed out, low latency is only one of several > > known use cases that would be worthwhile to identify to an AQM > > scheduler, which the L4S approach cannot be extended to handle: > > - Minimize Latency > > - Minimize Loss > > - Minimize Cost > > - Maximize Throughput > > https://lists.bufferbloat.net/pipermail/ecn-sane/2019-March/000066.html > > I understand that "Minimize Cost" is perhaps covered by LEPHB, and that > > operator tuning parameters for a dualq node can possibly allow for > > tuning between minimizing loss and latency, as mentioned in section > > 4.1 of aqm-dualq, but since the signaling is bundled together, it can > > only happen for one at a time, if I'm reading it right. > > But more importantly, the L4S usage couples the minimized latency use > > case to any possibility of getting a high fidelity explicit congestion > > signal, so the "maximize throughput" use case can't ever get it. > > Regards, > > Jake > > PS: > > If you get a chance, I'm still interested in seeing answers to my > > questions about deployment mitigations on the tsvwg list: > > https://mailarchive.ietf.org/arch/msg/tsvwg/TWOVpI-SvVsYVy0_U6K8R04eq3A > > I'm not surprised if it slipped by unnoticed, there have been a lot of > > emails on this. But good answers to those questions would go a long way > > toward easing my concerns about the urgency on this discussion. > > PPS: > > These issues are a bit sideways to my technical reasons for preferring > > the SCE formulation of ECT(1), which have more to do with the confusing > > semantics and proliferation of corner cases it creates for CE and ECE. > > But I thought I’d ask about them since it seemed like maybe there was a > > disconnect here. > > *From: *Bob Briscoe <ietf@bobbriscoe.net> > *Date: *2019-03-18 at 18:07 > *To: *"David P. Reed" <dpreed@deepplum.com>, Vint Cerf <vint@google.com> > *Cc: *tsvwg IETF list <tsvwg@ietf.org>, bloat > <bloat@lists.bufferbloat.net> > *Subject: *Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] > Implementation and experimentation of TCP Prague/L4S hackaton at IETF104 > > David, > > On 17/03/2019 18:07, David P. Reed wrote: > > Vint - > > BBR is the end-to-end control logic that adjusts the source rate > to match the share of the bolttleneck link it should use. > > It depends on getting reliable current congestion information via > packet drops and/or ECN. > > So the proposal by these guys (not the cable guys) is an attempt > to improve the quality of the congestion signal inserted by the > router with the bottleneck outbound link. > > What do you mean 'not the cable guys'? > This thread was reasonably civil until this intervention. > > > THe cable guys are trying to get a "private" field in the IP > header for their own use. > > > There is nothing private about this codepoint, and there never has > been. Here's some data points: > > * The IP header codepoint in question (ECT(1) in the ECN field) was > proposed for use as an alternative ECN behaviour in July 2105 in the > IETF AQM WG and the IETF's transport area WG (which handles all ECN > matters). > * A year later there followed a packed IETF BoF on the subject (after > 2 open Bar BoFs). > * Long discussion ensued on the merits of different IP header field > combinations, on both these IETF lists, involving people active on > this list (bloat), including Dave Taht, who is acknowledged for his > contributions in the IETF draft. > * That was when it was decided that ECT(1) was most appropriate. > * The logic of the decision is written up in an appendix of > draft-ietf-ecn-l4s-id. > * David Black, one of the co-chairs of the IETF's transport area WG > and co-author of both the original ECN and Diffserv RFCs, wrote > RFC8311 to lay out the process for reclaiming and reusing the > necessary codepoints. > * This work and the process of freeing up codepoints has been very > visible at every IETF ever since, with multiple drafts to fix other > aspects of the protocols working their way through the IETF process in > multiple WGs (tsvwg, tcpm, trill, etc). > * L4S has also been mentioned in IETF liaisons with the IEEE and 3GPP. > > Some history: > * I had been researching the idea since 2012. > * In fact my first presentation on it was scheduled directly after Van > Jacobson's first presentation of CoDel at the IETF in July 2012. VJ > overran by nearly 20mins leaving just 3 mins for my presentation. > * Mirja Kuehlewind and I did early groundwork in 2013 and published a > paper > * Then I (working for BT) brought the work into the EU RITE project > (Reducing Internet Transport Latency) with Simula, Alcatel-Lucent, etc. > * By 2015 the two main L4S proponents were Koen De Schepper from > Alcatel Lucent and myself (I had just switched from BT to Simula), > along with Olga Bondarenko (now Albisser), a PhD student at Simula who > now works for Microsoft (on something else) and is still doing her PhD > part-time with Simula > o By that time, Al-Lu and Simula had a cool prototype running. > o This was demonstrated publicly for the first time in the IETF AQM > WG over DC+core+backhaul+DSL+home networks. > https://riteproject.eu/dctth/#1511dispatchwg > <https://urldefense.proofpoint.com/v2/url?u=https-3A__riteproject.eu_dctth_-231511dispatchwg&d=DwMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=zfPW2a1vuvsWS3Jyy_VK9_HR7vCG_9ICWuN2-7yuuPU&s=W5ZSTVXb4iSChTS8-sSOHWDszX3AitVf8Qwh-dXbqCY&e=> > * In May 2016, L4S was demonstrated at MultiMediaSystems'16 with > /every/ packet from all the following simultaneous applications > achieving ~1ms queuing delay or less over a 40Mb/s Internet access > link (7ms base RTT): > o cloud-rendered remote presence in a racing car within a VR headset > o the interactive cloud-rendered video already linked above > o an online gaming benchmark > o HAS video streaming > o a number of bulk file downloads > o a heavy synthetic load of web browsing > > L4S has never been access-technology-specific. Indeed the cable > industry has been funding my work at the IETF to help encourage a > wider L4S ecosystem. There is nothing private to the cable industry in > this: > * Al-Lu used DSL as a use-case, but L4S was relevant to all the access > technologies they supplied. > * BT was obviously interested in DSL, > * but BT's initial motivating use-case was to incrementally deploy the > low queuing delay of DCTCP over BT's data centre interconnect networks. > * In Jul 2016 the open-source Linux repo for the Coupled AQM was > published, with a fully working version to be used and abused. > Now at: https://github.com/L4STeam/sch_dualpi2_upstream > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_L4STeam_sch-5Fdualpi2-5Fupstream&d=DwMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=zfPW2a1vuvsWS3Jyy_VK9_HR7vCG_9ICWuN2-7yuuPU&s=IrFWAYZca2EEiXNTyliUfh3DgYYEyvabNTq8xYIQjBQ&e=> > * Of course, DCTCP was already open-sourced in Linux and FreeBSD, as > well as available in Windows > * In Jul 2016, the main IETF BoF on L4S was held: > o Ingemar Johansson from Ericsson was one of the proponents, focused > on using L4S in LTE > o along with Kevin Smith from Vodafone and > o Praveen Balasubramanian from Microsoft (who maintains the Windows > TCP stack, including DCTCP). > o Ingemar has since written an open-source L4S variant of the SCReAM > congestion controller for real-time media: > https://github.com/EricssonResearch/scream/ > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_EricssonResearch_scream_&d=DwMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=zfPW2a1vuvsWS3Jyy_VK9_HR7vCG_9ICWuN2-7yuuPU&s=KudwyCeLp1jJbSm0Qv-Rm45UKacU0Q0rtT_Kca9Z2uA&e=> > o Mirja Kuehlewind of ETHZ (and now Ericsson) implemented the > necessary feedback in TCP https://github.com/mirjak/linux-accecn > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_mirjak_linux-2Daccecn&d=DwMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=zfPW2a1vuvsWS3Jyy_VK9_HR7vCG_9ICWuN2-7yuuPU&s=8xmJipLHdxCtcbf-ZSYOZUWjzgNd8p0dF4XTOe-Lwxo&e=> > * In summer 2017 CableLabs started work on Low Latency DOCSIS, and > hired me later in the year to help develop and specify it, along with > support for L4S > o In Jan 2019 the Low Latency DOCSIS spec was published and is now > being implemented. > o You can find the primary companies involved at the end of the > White Paper. > https://cablela.bs/low-latency-docsis-technology-overview-february-2019 <https://urldefense.proofpoint.com/v2/url?u=https-3A__cablela.bs_low-2Dlatency-2Ddocsis-2Dtechnology-2Doverview-2Dfebruary-2D2019&d=DwMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=zfPW2a1vuvsWS3Jyy_VK9_HR7vCG_9ICWuN2-7yuuPU&s=rAKo34ElWnLOIk827MWT75KG3rrRmc6dM3UaTtC9VBc&e=> > o Operators: > Liberty Global > Charter > Rogers > Comcast > Shaw > Cox Communications > o Equipment vendors > ARRIS > Huawei > Broadcom > Intel > Casa > Nokia > Cisco > Videotron > * Nicolas Kuhn of CNES has been assessing the use of L4S for satellite. > * Magnus Westerlund of Ericsson with a team of others has written the > necessary ECN feedback into QUIC > * L4S hardware is also being implemented for hi-speed switches at the > moment > (the developer wants to announce it themselves, so I have been > asked not to identify them). > > There's a lot more stuff been going on, but I've tried to pick out > highlights. > > All this is good healthy development of much lower latency for > Internet technology. > > > I find it extremely disappointing that some people on this list are > taking such a negative attitude to the major development in their own > field that they seem not to have noticed since it first hit the > limelight in 2015. > > L4S has been open-sourced since 2016 so that everyone can develop it > and make it better... > > If I was in this position, having overlooked something important for > multiple years, I would certainly not condemn it while I was trying to > understand what it was and how it worked. Can I suggest everyone takes > a step back, and suspends judgement until they have understood the > potential, the goals and the depth of what they have missed. People > who know me, know that I am very careful with Internet architecture, > and particularly with balancing public policy against commercial > issues. Please presume respect unless proven otherwise. > > Best Regards > > > > Bob > > PS. Oh and BBR would be welcome to use the ECT(1) codepoint to get > into the L4S queue. But only if it can keep latency down below around > 1ms. Currently those ~15-25ms delay spikes would not pass muster. > Indeed, its delay is not consistently low enough between the spikes > either. > > > > > -----Original Message----- > From: "Vint Cerf" <vint@google.com> <mailto:vint@google.com> > Sent: Saturday, March 16, 2019 5:57pm > To: "Holland, Jake" <jholland@akamai.com> <mailto:jholland@akamai.com> > Cc: "Mikael Abrahamsson" <swmike@swm.pp.se> > <mailto:swmike@swm.pp.se>, "David P. Reed" <dpreed@deepplum.com> > <mailto:dpreed@deepplum.com>, "ecn-sane@lists.bufferbloat.net" > <mailto:ecn-sane@lists.bufferbloat.net> > <ecn-sane@lists.bufferbloat.net> > <mailto:ecn-sane@lists.bufferbloat.net>, "bloat" > <bloat@lists.bufferbloat.net> <mailto:bloat@lists.bufferbloat.net> > Subject: Re: [Ecn-sane] [Bloat] [iccrg] Fwd: [tcpPrague] > Implementation and experimentation of TCP Prague/L4S hackaton at > IETF104 > > where does BBR fit into all this? > > v > > On Sat, Mar 16, 2019 at 5:39 PM Holland, Jake <jholland@akamai.com > <mailto:jholland@akamai.com>> wrote: > > On 2019-03-15, 11:37, "Mikael Abrahamsson" <swmike@swm.pp.se > <mailto:swmike@swm.pp.se>> wrote: > L4S has a much better possibility of actually getting > deployment into the > wider Internet packet-moving equipment than anything being > talked about > here. Same with PIE as opposed to FQ_CODEL. I know it's > might not be as > good, but it fits better into actual silicon and it's > being proposed by > people who actually have better channels into the people > setting hard > requirements. > > I suggest you consider joining them instead of opposing them. > > > Hi Mikael, > > I agree it makes sense that fq_anything has issues when you're > talking > about the OLT/CMTS/BNG/etc., and I believe it when you tell me PIE > makes better sense there. > > But fq_x makes great sense and provides real value for the > uplink in a > home, small office, coffee shop, etc. (if you run the final > rate limit > on the home side of the access link.) I'm thinking maybe > there's a > disconnect here driven by the different use cases for where > AQMs can go. > > The thing is, each of these is the most likely congestion point at > different times, and it's worthwhile for each of them to be > able to > AQM (and mark packets) under congestion. > > One of the several things that bothers me with L4S is that > I've seen > precious little concern over interfering with the ability for > another > different AQM in-path to mark packets, and because it changes the > semantics of CE, you can't have both working at the same time > unless > they both do L4S. > > SCE needs a lot of details filled in, but it's so much cleaner > that it > seems to me there's reasonably obvious answers to all (or > almost all) of > those detail questions, and because the semantics are so much > cleaner, > it's much easier to tell it's non-harmful. > > <aside regarding="non-harmful"> > The point you raised in another thread about reordering is mostly > well-taken, and a good counterpoint to the claim "non-harmful > relative > to L4S". > > To me it seems sad and dumb that switches ended up trying to make > ordering guarantees at cost of switching performance, because > if it's > useful to put ordering in the switch, then it must be equally > useful to > put it in the receiver's NIC or OS. > > So why isn't it in all the receivers' NIC or OS (where it > would render > the switch's ordering efforts moot) instead of in all the > switches? > > I'm guessing the answer is a competition trap for the switch > vendors, > plus "with ordering goes faster than without, when you > benchmark the > switch with typical load and current (non-RACK) receivers". > > If that's the case, it seems like the drive for a competitive > advantage > caused deployment of a packet ordering workaround in the wrong > network > location(s), out of a pure misalignment of incentives. > > RACK rates to fix that in the end, but a lot of damage is > already done, > and the L4S approach gives switches a flag that can double as > proof that > RACK is there on the receiver, so they can stop trying to > order those > packets. > > So point granted, I understand and agree there's a cost to > abandoning > that advantage. > </aside> > > But as you also said so well in another thread, this is > important. ("The > last unicorn", IIRC.) How much does it matter if there's a > feature that > has value today, but only until RACK is widely deployed? If > you were > convinced RACK would roll out everywhere within 3 years and > SCE would > produce better results than L4S over the following 15 years, > would that > change your mind? > > It would for me, and that's why I'd like to see SCE explored > before > making a call. I think at its core, it provides the same > thing L4S does > (a high-fidelity explicit congestion signal for the sender), > but with > much cleaner semantics that can be incrementally added to > congestion > controls that people are already using. > > Granted, it still remains to be seen whether SCE in practice > can match > the results of L4S, and L4S was here first. But it seems to > me L4S comes > with some problems that have not yet been examined, and that > are nicely > dodged by a SCE-based approach. > > If L4S really is as good as they seem to think, I could > imagine getting > behind it, but I don't think that's proven yet. I'm not > certain, but > all the comparative analyses I remember seeing have been from > more or > less the same team, and I'm not convinced they don't have some > misaligned incentives of their own. > > I understand a lot of work has gone into L4S, but this move to > jump it > from interesting experiment to de-facto standard without a > more critical > review that digs deeper into some of the potential deployment > problems > has me concerned. > > If it really does turn out to be good enough to be permanent, > I'm not > opposed to it, but I'm just not convinced that it's > non-harmful, and my > default position is that the cleaner solution is going to be > better in > the long run, if they can do the same job. > > It's not that I want it to be a fight, but I do want to end up > with the > best solution we can get. We only have the one internet. > > Just my 2c. > > -Jake > > > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > <mailto:Ecn-sane@lists.bufferbloat.net> > https://lists.bufferbloat.net/listinfo/ecn-sane > <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.bufferbloat.net_listinfo_ecn-2Dsane&d=DwMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=zfPW2a1vuvsWS3Jyy_VK9_HR7vCG_9ICWuN2-7yuuPU&s=6aOGTXQW4Yh0LX-6RMhcK4d8BixblVH6c-yIGT7IVS8&e=> > > > -- > > New postal address: > > Google > > 1875 Explorer Street, 10th Floor > > Reston, VA 20190 > > > > _______________________________________________ > > Bloat mailing list > > Bloat@lists.bufferbloat.net <mailto:Bloat@lists.bufferbloat.net> > > https://lists.bufferbloat.net/listinfo/bloat <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.bufferbloat.net_listinfo_bloat&d=DwMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=zfPW2a1vuvsWS3Jyy_VK9_HR7vCG_9ICWuN2-7yuuPU&s=SQx_1nK8EWZnWRYRJfdA_I-eLl0XlKNoC6YRxjfVdkw&e=> > > > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__bobbriscoe.net_&d=DwMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=zfPW2a1vuvsWS3Jyy_VK9_HR7vCG_9ICWuN2-7yuuPU&s=wzv0H2d7H27kBtLtx2XWzBZkzJ_s0BmWpPnMn9B7Pc8&e=> Concerning "Maximize Throughput", if you don't need scalability to very high rates, then is your requirement met by TCP-like semantics, as in TCP with SACK/loss or even better TCP with ABE/ECT(0)? I wonder .... if the intent is to scale to really high rates, then the control loop delay for the congestion-controller becomes a limiting issue, and in that case low-latency is necessary to safely climb the rate to the high speed - and conversely to allow the controller to react quickly when (or if) that overshoots a capacity bottleneck. In other words, is scalable high throughput inseperable from low latency? Gorry
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Bob Briscoe
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Dave Taht
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Jonathan Morton
- Re: [tsvwg] Implementation and experimentation of… Greg White
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Dave Taht
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Ingemar Johansson S
- Re: [tsvwg] [Ecn-sane] [Bloat] [iccrg] Fwd: [tcpP… Sebastian Moeller
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Holland, Jake
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Gorry Fairhurst
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Stephen Hemminger
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Holland, Jake
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Jonathan Morton
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Jonathan Morton
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Holland, Jake
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Greg White
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Greg White
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Jonathan Morton
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Holland, Jake
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Greg White
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Bob Briscoe
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Jonathan Morton
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Holland, Jake
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Bob Briscoe
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Jonathan Morton
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Bob Briscoe
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Sebastian Moeller
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Bless, Roland (TM)
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Bob Briscoe
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Bless, Roland (TM)
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Bob Briscoe
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Bob Briscoe
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… alex.burr@ealdwulf.org.uk