[iccrg] BBR and acking stagnant windows
Martin Duke <martin.h.duke@gmail.com> Tue, 19 November 2019 04:59 UTC
Return-Path: <martin.h.duke@gmail.com>
X-Original-To: iccrg@ietfa.amsl.com
Delivered-To: iccrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B63112008A for <iccrg@ietfa.amsl.com>; Mon, 18 Nov 2019 20:59:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 BdaK-Skb_pJG for <iccrg@ietfa.amsl.com>; Mon, 18 Nov 2019 20:59:21 -0800 (PST)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 3173C1207FB for <iccrg@irtf.org>; Mon, 18 Nov 2019 20:59:21 -0800 (PST)
Received: by mail-wr1-x434.google.com with SMTP id a15so22168229wrf.9 for <iccrg@irtf.org>; Mon, 18 Nov 2019 20:59:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=sSgmzDEs60J5udJvCEyqOCBR9EhFNXiI8YqKmdxzB+A=; b=J9XimVjP+Vc3jbePj9MN5nAQBxjo/x0CfZbyepgA+GhEKin0rAqlEuDZCMxIXGKiQn f25LWmlg1h8L9ac75YxmYDUHo4YDBq7qsLPVNbfl+p+xOeOl4LdPtoT9edv9UqWP1o9E BzeExrBG/VP+weXGDwqlPh7Wx95EkfClvRdiA88QOtVxNFwlZz7RzV5bANPWVU9hBwN4 LEkGG4wRjUosngo9HDCkoMF0T02DirOJkszs0eaWBJSSeA2dwZRUAnlJth2jA351upTJ xn82LeiVdL/tYQsE3AXZ2dpByzuQEL3YfQhCQQ9K0Y1kpaDe86s213SykF8EEB9y4zhj 045g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=sSgmzDEs60J5udJvCEyqOCBR9EhFNXiI8YqKmdxzB+A=; b=TEWwlCjfU4HRZg0Y979m5z9x4K3Rr8cGodNKDxreiG8dQMNHe+17xslUd0WkEGr58H +j8Q32aGVeOWdacZhfDPm8sICMp6ELvSZlOSv3ZG5AqYkdv3zxi9pYgFIUQovRd5sAoe Nq9en+H2hODjLxuKindEe8bqPEOYxXt/tUqyDW0E7e4cZ13jlboP5ZqVhnf67Oc4+NRZ 9TMtO6vszEjo8QBjD3eNZ1CRpwMgzu9w4QNbRp9aiL+Ly6W9iWuCLmJPgl9Qf20vRiyj /5u9bWgWQAzialI+B01v44iYx4Mg6ZOa6Z+PWFrdCkWjRQeHitBU9JM05NFICCUjKnYE RXFQ==
X-Gm-Message-State: APjAAAUP/GniQv0FxCqCSJqps/5EJWS4BS12xKpfDHZoj3BLWXYrjmHk 6RJeN1exiLuiAZzJ3ysa1T+og9bvAPlz/ERB83E=
X-Google-Smtp-Source: APXvYqy7qwzzY4kyizuoWNgsqaRIEpzFX9C9t8Uhf3291JoIR3IZAtXmmXJM1lTAeo5H4XXpMqXXO7usCxYDhxNZBqw=
X-Received: by 2002:a5d:55c7:: with SMTP id i7mr36076079wrw.64.1574139559581; Mon, 18 Nov 2019 20:59:19 -0800 (PST)
MIME-Version: 1.0
From: Martin Duke <martin.h.duke@gmail.com>
Date: Tue, 19 Nov 2019 12:59:08 +0800
Message-ID: <CAM4esxS3wSaccYYmCHH6O9k+0FZ-f2fdpMoHG1oDBbKAU5piHw@mail.gmail.com>
To: Neal Cardwell <ncardwell@google.com>
Cc: iccrg@irtf.org
Content-Type: multipart/alternative; boundary="000000000000469fa10597abedfa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/iccrg/eShcIqdEtnsigo-r03MQAKgUMeU>
Subject: [iccrg] BBR and acking stagnant windows
X-BeenThere: iccrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" <iccrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/iccrg>, <mailto:iccrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iccrg/>
List-Post: <mailto:iccrg@irtf.org>
List-Help: <mailto:iccrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/iccrg>, <mailto:iccrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Nov 2019 04:59:24 -0000
Neal, I'd like to follow up on our discussion in Singapore. I have no special knowledge of why Linux doesn't ack when the window doesn't move, but perhaps you can help me reason about it. >From the most abstract principle, it seems sensible that if an endpoint can only process 100kbps, I wouldn't give it more bandwidth than that. That's what the current code does. However, considering the practical case, what would be the impact of removing this line of code? 1) if the connection is almost done, it can complete faster by consuming the relevant rwnd. 2) the RTT estimate will be closer to min_rtt, for algorithms that care. 3) if not done, we will end up rwnd-limited rather than cwnd-limited. I am less comfortable reasoning about this, but this may lead to burstier traffic and periods of idleness waiting for zero-window probes. Anyway, you alluded to some particular RPC use cases that causes more serious problems. Can you elaborate? Martin
- [iccrg] BBR and acking stagnant windows Martin Duke
- Re: [iccrg] BBR and acking stagnant windows Neal Cardwell