From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 0C1913B29E; Sat, 16 Mar 2019 20:58:53 -0400 (EDT) Received: by mail-lf1-x12f.google.com with SMTP id a6so6942985lfl.5; Sat, 16 Mar 2019 17:58:52 -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=krZivQClUqxY2xIVPINHTLuG09Gdz/cmcrwxdcsUDmM=; b=GBmNueROCHo2HwB1+1KXEC0kNsDfwqsY/01bT3kHUhFnuUkAOWz/1vmMi/Ze1C3/Cq 76KZg34M69JbIITKMgMuZDCIgfD4fYTD8b5H0aMF0chLU5oxbaosbEnwV7j5qhniovRD wgbYNsbYscC/uIr6KxZTFCqVLqP5L7s7GAL/rcR8pTAziav3Y2W2AK10XdIQXWAsqSxT Zo8HbmOlW0KS4BztQ0NRO13MydHblHfMMnxnjONNs7ssyg5U+FWoKlRKrS63AKk3WaYR arNiquj0/TrsUhCtDp+pvvBa4jVvic08vIPytc9mesEDrf7YbRjKitZQaoW9Bwzne/j5 SUPg== 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=krZivQClUqxY2xIVPINHTLuG09Gdz/cmcrwxdcsUDmM=; b=odcF0mySPBYrLSJ8ZqX5yCkhqo6Cf0eCaBbgwH0+Cc0hzqIHQY5Qckrb3U+80mLfur SN0Qt5OPMgcPxY/lJ5anZ4SpSk0tVHOK1rpLVWW6vE8pYoUuSxWBSAAOTfyBY4WgGIe4 DlqfE7rc9/8196Lkxmgt2drWRaqt8CQ/pyuPnCOgqCOYbaPC7AbBA1gZBmVv3YFPLUPK CGyVtXfhrgNta/rZvShBkl08iQdGz41cffm/hFdz4yISH2NONPLkcgk2kI697CdKV9CB fgYVPvwjIl2X3mwM5CottwsZEtWg3nJq+KFLsOKosx0uIRqej9K7CqK6KHpuofv66Rtz KORg== X-Gm-Message-State: APjAAAX0QlOAbWtHCDtk/HfcGEmBJkbOkCN5MSsYNzVdJmvkyuH+Kc8j iScXNpSEQMFUV6GbqKL+i4M= X-Google-Smtp-Source: APXvYqw7ErKd/oGlWNmbH8yTx3OVl85Y/Zbh4tNkFDKsCBTVe+ittKzo1xFOm/lbxO70HUxjetL5kg== X-Received: by 2002:ac2:5325:: with SMTP id f5mr5984246lfh.77.1552784331975; Sat, 16 Mar 2019 17:58:51 -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 r12sm1212032ljc.97.2019.03.16.17.58.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Mar 2019 17:58:51 -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: <3BED3588-B6CC-4659-BEED-32AC4095CB73@akamai.com> Date: Sun, 17 Mar 2019 02:58:49 +0200 Cc: "ecn-sane@lists.bufferbloat.net" , bloat Content-Transfer-Encoding: quoted-printable Message-Id: References: <3BED3588-B6CC-4659-BEED-32AC4095CB73@akamai.com> To: "Holland, Jake" X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Bloat] [Ecn-sane] SCE receiver-side vs. sender-side response 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: Sun, 17 Mar 2019 00:58:53 -0000 > On 17 Mar, 2019, at 12:25 am, Holland, Jake = wrote: >=20 > I do think that to capture the value here, the SCE rate probably has = to > get back to sender, but I think there's good options for doing so, and > anywhere it doesn't work, (I think?) it just falls back to regular CE, > which is a nice bonus that comes from backward compatibility. Yes, I think you've got the right idea here. > 3. new TCP header flag plus URG pointer space: > It's also not hard to imagine extending #2 so that it's incompatible > with URG on the same packet (which mostly nobody uses, AFAIK?), and > using the URG ptr space to report a fixed-point value for SCE rate = over > a defined time span or packet count or something. Using the urgent-pointer field is indeed another possibility, since URG = is never legally set on pure acks and is rare on data segments as well = (FTP uses it), and the field is unused with URG cleared. So the need to = send both URG data and SCE feedback at the same time is a rare corner = case but shouldn't be too difficult to code around. I think there may still be a problem with paranoid middleboxes erasing = the information in that field when URG is cleared, probably because it = could be used as an exfiltration channel. These may be the same set of = paranoid middleboxes that erase unknown TCP options. But this should = both be detectable by the new flag being set while the field stays = cleared, and basically harmless because there is that fallback to = standard ECN - provided the affected packets are not actually dropped = rather than just sanitised. > I think this receiver-driven idea is doomed. I mean, good luck and = it's a neat idea > if it works, but it's got some problems with flexibility: > - you don't want to reduce right edge of window, so you can't reduce > rwnd faster than data is arriving. This is not inherently a problem, because the receiver can act on = congestion information a full RTT before the sender; assuming the = receiver is actually controlling the congestion window, halting the = advance of the right edge is equivalent to snapping the cwnd completely = shut (to zero) at the sender based on the same information. This is a = more aggressive response than any real congestion control algorithm = exercises. > - growing rwnd won't grow cwnd automatically at that rate, so it's = only > a cap on how fast cwnd can grow, not a way to make it actually grow > from the sender's side. As long as the receiver-side congestion control is less aggressive about = growth and more aggressive about shrinking than the sender-side, the = former will control the effective congestion window. Of course, it = could be that the sender uses NewReno which is as meek as a lamb about = growth (one MSS per RTT once out of slow-start), and then a = receiver-side algorithm may be acting on congestion signals relevant for = a much smaller window than it has maintained. So that is a potential complication. A mechanism might be needed to = infer the sender's cwnd from timestamp information and feed that into = the receiver cwnd calculations. It might also be best to engage the more limited rwnd only when SCE = information warrants it, and leave the responses to CE and loss entirely = to the sender. This would still require maintaining the on-wire rwnd = small enough to be engaged at relatively short notice, yet large enough = to accommodate reasonable sender-side cwnd evolutions, using inferment = of the current cwnd as a guide. - Jonathan Morton