From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 4E24F3BA8E; Tue, 19 Mar 2019 03:10:56 -0400 (EDT) Received: by mail-lf1-x12d.google.com with SMTP id m13so13589899lfb.6; Tue, 19 Mar 2019 00:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wjurm6tP/RvqSBvQWwVPH+wJdeel5S29vpDP+7Wj3FE=; b=g/Ise7+m35aptQA5bPCl+JgmWEgdg2VM1MmOhJf1JHpK9/V6wPqnoweDPOlw4ScNZo K6GarrcTz5AJtGlPKJAMASUFhyh433VnlsmLgACcPBy0oksUWOeqWq4rcv3tRjshyTT+ 1lNNpxeLv+NJ0AptdydjG2lFV0ejXWZ8Ps2m/dXZZ5UbyDZevXaOrYOdNCf5nUW5xn3z 5PlZg2xahRTknq81TvvMH76wW/hspcrSCAPesCi8gAww4+DsncUzg9VCtbrzyAO087HQ /yxVRVeORbtZDiDTCbhFfzNozGbS20IJWkWwd7TDeQ5fMMWpOslSRvODxM3iYrt2A5Id IW4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wjurm6tP/RvqSBvQWwVPH+wJdeel5S29vpDP+7Wj3FE=; b=EjnTOSTGh4Xlezf1b8Li+thnnkEAr+WFpIbH0Gm/2P5sASYvePB8yAyXFYVw/Gadj6 WQcp+qVkBSZ7SxQn5s8s2HM4PovmtHP9em/W5ltU9bKaUMrAWxX7SH9m51mMdKuqgzWW qiiGD3nj+hsR8RKwUXlltBPP8F9Qj3gNGg46AGb2UgI3l4+1q/gvZVBf7Re7S70WQzV5 jxZnXDYZbltIz9B2XFlQOMgO/woB3sOYSTdNj9UTYBkSqWNYVHQsTXEakvdZoi5QK4OV W6Vbi/1rHKUxVZgPRw/uzA0AEQbe5GbzpIaEicNtKV/TOWEOMj86qjGlfQIJNk+jI1mj LZtg== X-Gm-Message-State: APjAAAUBV1w8k6Rsw+8KoVnCo8kgnnzNp55+tHCiFK/vCSuxdYsZRidC 9LlhZv70fIhKN7dHRUEas1s= X-Google-Smtp-Source: APXvYqyN3gt7Zckxh0pb+gMEtgfrrM5LwDTkASwjTg76CmiCeNL/p94KwIfuHqaqLlAIk3cB8UN7PA== X-Received: by 2002:ac2:5966:: with SMTP id h6mr11630364lfp.86.1552979455320; Tue, 19 Mar 2019 00:10:55 -0700 (PDT) Received: from jonathartonsmbp.lan (83-245-227-44-nat-p.elisa-mobile.fi. [83.245.227.44]) by smtp.gmail.com with ESMTPSA id h1sm2592753ljb.87.2019.03.19.00.10.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Mar 2019 00:10:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: Date: Tue, 19 Mar 2019 09:10:52 +0200 Cc: "David P. Reed" , Vint Cerf , "ecn-sane@lists.bufferbloat.net" , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <3C188730-DCD1-4359-AA19-F7526ECDF111@gmail.com> References: <1E80578D-A589-4CA0-9015-B03B63042355@gmx.de> <27FA673A-2C4C-4652-943F-33FAA1CF1E83@gmx.de> <1552669283.555112988@apps.rackspace.com> <7029DA80-8B83-4775-8261-A4ADD2CF34C7@akamai.com> <1552846034.909628287@apps.rackspace.com> <93781542-6DD4-4840-A1C6-A5C28E40A0F7@gmail.com> To: Greg White X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104 X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 07:10:56 -0000 > On 19 Mar, 2019, at 7:52 am, Greg White wrote: >=20 > L4S utilizes TCP Prague, which falls back to traditional congestion = control if the bottleneck link doesn't provide isolation. =20 You see, this is the part I find difficult to believe that it will = operate reliably. For a start, I have seen no detailed public = description of TCP Prague, even though it has supposedly been in "open" = development for so long. My most recent information is that it's = essentially a slightly modified DCTCP. " It would take time for endpoints to distinguish classic and L4S ECN marking. An increase in queuing delay or in delay variation would be a tell-tale sign, but it is not yet clear where a line would be drawn between the two behaviours. " Internet history is littered with failed attempts at implementing = delay-sensitive TCPs. I can immediately think of several reasons why = delay can and will vary for reasons other than the bottleneck not = implementing an isolated queue (just ask the BBR devs). The mere = presence of a wifi link on the path, even if it is never the bottleneck, = would be a trivial and common example. So please explain (or point to good documentation) how TCP Prague = robustly avoids misbehaving in a standard ECN environment, as is = presently deployed. SCE explicitly does not rely on specific changes in behaviour by = endpoints. It just provides a conduit of information from the network = to the receiver, in addition to standard ECN behaviour. The receiver is = free to ignore that information, without harming the network, and will = naturally behave normally and safely when that information is absent. = We have a proof-of-concept implementation (a trivial mod of sch_codel = and sch_fq_codel) which successfully passes this information across the = Internet and works with (is transparently ignored by) existing endpoints = and middleboxes. In short, SCE is incrementally deployable by design. The broader system of feedback and modified congestion control, which I = call ELR (Explicit Load Regulation) as an umbrella term, offers benefits = which, yes, have not yet been proved - but which are straightforward in = concept and should be amenable to analysis. It seems likely that some = work from L4S can be used in this context. - Jonathan Morton