Re: [tcpm] ECN++: Congestion response to CE on Pure ACK

Neal Cardwell <ncardwell@google.com> Thu, 20 July 2017 15:12 UTC

Return-Path: <ncardwell@google.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4574D131CFC for <tcpm@ietfa.amsl.com>; Thu, 20 Jul 2017 08:12:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level:
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=google.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 Nly8crH4cC_e for <tcpm@ietfa.amsl.com>; Thu, 20 Jul 2017 08:12:10 -0700 (PDT)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 491C4131CE2 for <tcpm@ietf.org>; Thu, 20 Jul 2017 08:12:09 -0700 (PDT)
Received: by mail-oi0-x235.google.com with SMTP id p188so29499322oia.0 for <tcpm@ietf.org>; Thu, 20 Jul 2017 08:12:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GR0jINfBQmhhva/naDlI0Hx8s0IwlV8w99SngsyfYbg=; b=YUPVlcThxHpsIJDCSF7fdeKOpoOZddKuzPi5Q7N+DqigSoNXUsnGPIUeUwr+1ECkUE AtnymNw7BZnWRuQPUO6gi81kjeQrqMSzohLqRaq6jxTen2W81tf5a9Ih+kHjDQ9J3Wjl 4eU0zHlC+6wUDbCRjl8ThOR2AnjHzEvgvH/ptjj69nzSX+Vgw+VVQMiqtJ6x8PUwe+Bd BCyMBL5Q24xDNLAVz6gyemFZr5SbOV4TGdGfrCzWrNSklvHkTIHm78Bd6mwehgWiP89R srXNAlB72In7QBFV1wF3QCYOP9mjVk2pcoMplNoXovdUd9n7llX/FRa9igEiCVOQlu9R EhDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GR0jINfBQmhhva/naDlI0Hx8s0IwlV8w99SngsyfYbg=; b=t21QQUq+NIoUPxqqo0Y0b/0jayGTyiQw3b3erOMo9mmAbfMtl/pARMNeh/4N7u2pqr j1k+aapiyH6Re5Jp24736bEbvBM7KzJ6W9lhjvmm+JzvCPO9D0HSy/V5/PlBqFXXoDA4 aqgnLVv0GgXHDV8P5NTvZgNuvoiaiwGqfs5t8b4cdG6qhTJEm3R3jey5rCQU5jCZuaTW X9eGVNF0rOoT0Jb5Qan9ecs2FHgwFfoP6QpLhlrMBEJgjetWDBwOe6DHYUVbpqSLOyPS Ekui+x6nDQlHcsI17x/uKngART+WAELJ5Il5OfQM8y6cwNvwEb8e4VMbfsr64e2bBF6Y 38cw==
X-Gm-Message-State: AIVw113u+5AlFmZnqdOtmg9Bk6xZQWqM6n2kIuNFgbqVO5AtUE5eDGyP lOEf0Hrb+b2jnOWnnA4/64aVoM4x+UqP0Ksn4A==
X-Received: by 10.202.62.139 with SMTP id l133mr6438021oia.47.1500563528336; Thu, 20 Jul 2017 08:12:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.52.67 with HTTP; Thu, 20 Jul 2017 08:11:37 -0700 (PDT)
In-Reply-To: <F1C1D5B02EA3FA4A8AF54C86BA4F325CF0CB5C@DGGEMA501-MBX.china.huawei.com>
References: <dbb759a8-acea-2df3-d982-4397372950ae@bobbriscoe.net> <fc9169d8-c0d4-0705-1b96-009172144d73@wizmail.org> <CADVnQynh0dhPbd1DTAJgv7Encit4PRCs-sDxuGas94r6LNZKeA@mail.gmail.com> <F1C1D5B02EA3FA4A8AF54C86BA4F325CF0CB5C@DGGEMA501-MBX.china.huawei.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Thu, 20 Jul 2017 11:11:37 -0400
Message-ID: <CADVnQymXx=-aeCj=sVbv9r-E6yLQbSxXYCkH4or1Fb+JzMwFgA@mail.gmail.com>
To: "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>
Cc: Jeremy Harris <jgh@wizmail.org>, "tcpm@ietf.org" <tcpm@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/VRoXXs3w2-Ycx14MCHxZNHojZBE>
Subject: Re: [tcpm] ECN++: Congestion response to CE on Pure ACK
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Jul 2017 15:12:11 -0000

On Thu, Jul 20, 2017 at 2:17 AM, Gengxuesong (Geng Xuesong)
<gengxuesong@huawei.com> wrote:
> Hi Neal
>
> I think it is a very interesting discussion about the interaction between BBR and ECN.
> You mentioned that " since ECN schemes typically mandate a particular cwnd response from a sender ". Do you mean that the conflict between ECN and BBR is the conflict between cwnd mode and pacing mode?
> In other word, do you think if ECN is used as a signal of modifying pacing rate, these two mechanisms may work together well?

I didn't really mean the distinction between control via cwnd vs
control via pacing rate. I meant the deeper question of whether a
congestion control algorithm should simply have a fixed back-off
response to losses (Reno, CUBIC) or ECN marks (RFC 3168, DCTCP), or
whether the algorithm should try to make an independent estimate of
the capacity available to the flow (BBR).

But if someone wants an extended discussion of BBR and ECN, I'd
suggest that this should move to a separate thread, so that this
thread can stay focused on the original issues Bob raised in this
thread.

thanks,
neal