Re: [tcpm] A possible simplification for AccECN servers

Matt Mathis <mattmathis@google.com> Wed, 11 December 2019 18:07 UTC

Return-Path: <mattmathis@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 CEF77120088 for <tcpm@ietfa.amsl.com>; Wed, 11 Dec 2019 10:07:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 0glgrYyjNU1a for <tcpm@ietfa.amsl.com>; Wed, 11 Dec 2019 10:07:54 -0800 (PST)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 02B32120024 for <tcpm@ietf.org>; Wed, 11 Dec 2019 10:07:53 -0800 (PST)
Received: by mail-io1-xd29.google.com with SMTP id a22so8676690ios.3 for <tcpm@ietf.org>; Wed, 11 Dec 2019 10:07:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5Rw5jfEfogMWtdm5X2EMA7NMs4EfIfcqKQWS9qbQ15Y=; b=vtrV74fmUEyoHXOyHKfuFMpfSxSJpumkvukxMkVA8WD5d0RirvXj86xHROE0sEJFLb 4njPrREccWsZls0tS86Anh92eKRffp3x4MX6goN4bHTyhKLTvQztWT7tI/2AmdBl96uw g630W7ro/HKJtJpxL0nLhoM1ALXRIboQJvihEfLnhTxkN7lLelNHBbjITvxe4lxJxctK AgWHvCsurFjE8eZynm+T4Kj6S3AsZyRVyliU9NmtwTCyAphVOphmGJB0BBDooJRLXu9o iYksYvQSh2625uWNxGnWF50q84za3+Gl5GHg8p0gfBsBd3LHMs5jF0rpOqjRzY/EwVUW Se6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5Rw5jfEfogMWtdm5X2EMA7NMs4EfIfcqKQWS9qbQ15Y=; b=JpqSZ8y1UsjcUXxhxlYYgL2sOu5HdEzKMmeoRWKWw3/S7EZirs4rM0O3S1Xp+FHqi2 qrbHlgCVC+jq/o51BqI8xEC6BC/HVqwH7srZ1d2WZKVPE+q+L22IkBIZyDba93oL1FSv /3rUtVLM8Fv2E0Q4ppSWBjvCqv/XDD4ITsukkTPj2To8MB4sqX9HputllVUBhIKyNBf0 uboY4r99z1vdh23s3KS8o2vsd0ivDhDpQwvsEFHbCaBXdC9m3YIg3cPy1mrFp78bP3uC DgvHsNIQun3hMJeBMpflidGDEKg5l8IqGkjtTGQizdwtsD/TOk5gp484/0no0J+REKjX zxrQ==
X-Gm-Message-State: APjAAAUSADpqGVprtWL9svkUShXZeO/r4fRI03iuHIk7T9CZuuBFvGZV JoI+jlsBPiBae8zDMuR2gWDAgBNImyE2lLQm3xOOsw==
X-Google-Smtp-Source: APXvYqzaOef3CLHkqBo4/JnwIdZ/9OzDfzzR/7IViTJe4Z7JKiw25NJsQf2WRxcJLSzpptD8tGKjB4RSfReNFknA1o0=
X-Received: by 2002:a6b:ee17:: with SMTP id i23mr3784810ioh.0.1576087673057; Wed, 11 Dec 2019 10:07:53 -0800 (PST)
MIME-Version: 1.0
References: <d35618ee-c0dc-44ee-9e22-50bdabbe026c@bobbriscoe.net> <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net> <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net> <A76315DB-B3B4-45A4-A8CA-5F4701EB4085@gmail.com> <F90043A1-87F5-4DD1-BB11-AE8D2F3C5A7E@kuehlewind.net> <86dd14dc-0c24-d604-ea57-b280407a1a09@bobbriscoe.net> <CCA9AFF7-6EBB-4DB0-B851-7806B8E96871@kuehlewind.net> <74fe4c25-6ea2-ac5e-e59e-51acfd54be5f@bobbriscoe.net> <F74FD1C5-DB49-45FB-8AF8-73CCE1A125EC@kuehlewind.net> <6ea44dd6-e830-2bce-39a2-d0efd7a90b2e@bobbriscoe.net> <CAH56bmDWT7XoJY_THqgeJ-hiyXHNUtZ+bCfi2cNpt6kW9fqzoQ@mail.gmail.com> <1DF1AF6B-EEF9-4CE8-AEBC-553C0F9E0E90@gmail.com>
In-Reply-To: <1DF1AF6B-EEF9-4CE8-AEBC-553C0F9E0E90@gmail.com>
From: Matt Mathis <mattmathis@google.com>
Date: Wed, 11 Dec 2019 12:07:41 -0600
Message-ID: <CAH56bmAMj8kMU7d+rqDY82+PXuoq8_Xdr3DE5OQhJZZzO1QiHQ@mail.gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: Bob Briscoe <ietf@bobbriscoe.net>, Richard Scheffenegger <rscheff@gmx.at>, tcpm IETF list <tcpm@ietf.org>, Mirja Kuehlewind <ietf@kuehlewind.net>
Content-Type: multipart/alternative; boundary="000000000000e3b8c005997181e1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/4qyLORP9dVMRO7nH9BqlNPHAmuI>
Subject: Re: [tcpm] A possible simplification for AccECN servers
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 11 Dec 2019 18:07:56 -0000

Content providers who are using some version of DCTCP are constrained to
use the same switch markings for all flows.  It is inconceivable that
anybody would do 3168 in such an environment, however DCTCP and AccECN are
likely to work well enough to fly.

I think you underestimate how quickly server side 3168 will evaporate once
AccECN is far enough along, especially if we are explicit about
discouraging distros from shipping it on by default, so the only server
side 3168 is by people who are engaged in the research.   Remember, by
default content providers must stay up to date with upstream bug fixes.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

We must not tolerate intolerance;
       however our response must be carefully measured:
            too strong would be hypocritical and risks spiraling out of
control;
            too weak risks being mistaken for tacit approval.


On Wed, Dec 11, 2019 at 10:14 AM Jonathan Morton <chromatix99@gmail.com>
wrote:

> > On 11 Dec, 2019, at 5:43 pm, Matt Mathis <mattmathis=
> 40google.com@dmarc.ietf.org> wrote:
> >
> > As a general strategy I would strongly prefer to wrap all 3168
> compatibility language in SHOULDS, perhaps with a meta comment that this
> language will all be obsolete at some point in the future.
>
> I definitely object to the latter, not least because it's logically
> inconsistent with the handshake protocol.  Any AccECN client MUST be
> prepared to have their AccECN-requesting SYN interpreted as an RFC-3168 SYN
> by an RFC-3168 server, which will reply with an RFC-3168 SYN-ACK and
> thereby put the whole connection in RFC-3168 mode.
>
> Therefore, RFC-3168 clients will always be at least as prevalent as AccECN
> clients, *even if* AccECN servers for some unfathomable reason decide to
> drop RFC-3168 support.  I maintain that the advantage to doing so is
> negligible in the most favourable interpretation.
>
> Therefore, you *cannot* assume in AccECN specifications that RFC-3168 will
> "eventually" go away.
>
>  - Jonathan Morton
>
>