Re: Consensus call for Late-Stage documents, pre-IETF 108 edition

Ian Swett <ianswett@google.com> Fri, 24 July 2020 18:01 UTC

Return-Path: <ianswett@google.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F373A1132 for <quic@ietfa.amsl.com>; Fri, 24 Jul 2020 11:01:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, 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=unavailable 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 jy4LiKrbHR67 for <quic@ietfa.amsl.com>; Fri, 24 Jul 2020 11:01:35 -0700 (PDT)
Received: from mail-yb1-xb44.google.com (mail-yb1-xb44.google.com [IPv6:2607:f8b0:4864:20::b44]) (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 2F92C3A1104 for <quic@ietf.org>; Fri, 24 Jul 2020 11:01:35 -0700 (PDT)
Received: by mail-yb1-xb44.google.com with SMTP id m200so959121ybf.10 for <quic@ietf.org>; Fri, 24 Jul 2020 11:01:35 -0700 (PDT)
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=19Ic3bFcSGXusdq3YNGcASnDomWYaV51JlW/PTFuoL8=; b=kAp8Ln+ltyUdgfssVcqnaijQVm3UjAhl3NlJODo1UooL/PzDW/pYIxguOeKvM79Z28 5CdydMClmZH6bsF+5D2zwwjSyj7P0d03ga+ioRENYFDiVR/X4i89Yjk/h1Wa0bFa2WDK 5dHRsT9aOZkFM5bWNvC7oE1FdjyDizbvjVS/iG3achqhH/2YldVifT29t8XugkrCQqPN qITJOFNgqcUVoC8T2CuTGlexP1UkQCqrNJg7CFNe4PfTrBXADVIVbJRxYi7d8yNPf+oT VZ7OYP5t+6sp/lFGafOLJStXEQ3ficpeVgQMFnlVGz0Lz29kcgoGpet6zBorZBGmg5nb 9Zzg==
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=19Ic3bFcSGXusdq3YNGcASnDomWYaV51JlW/PTFuoL8=; b=SGYtepVF40vh5uMOUevAkFAxjnpfhdNjV12jLUkVmaTXmrbtKHCLG3OlMgG/E1vE33 6YwLB5YaEy85EZiiv6oRIexu/5DV4FKkc6eNRgOGv24gbNbCNG/W75nk4wTWiB9iiIwD x/QY6IVJcRVHUILoyDX46S+yq2emX1Bfvug4tnxd/XgaC4ECdOqByaAB1FSQZjU1uZju Y5jyftlUFL35OapZcbCQqth5lNW8dux1MMr0HkwVtoW/GTQsqYf4cAX2BNdO/EgxY4T2 rUe04wWFZFiq3MngBP56JTuUvNulqVIMhIM1Xs0NZzPNbHVq2dhaE0IcujLEaLxMzTuK KXPA==
X-Gm-Message-State: AOAM530773zm8cNfPiELTAfWJYO4slnn7bDCNTFLOFY5k46As5NPXr9x w8VUBLW465G8UGS2YBmvRgsW8b0bswsHVenF2ClMXw==
X-Google-Smtp-Source: ABdhPJwLOS9PjmxzW6dvstr+t9ZXJt6jLfjNRFQgHnm+NP81O8qaQXDPTRruCOyOqGL8fcJepN6kEqQjcO3fMD1B5GY=
X-Received: by 2002:a25:3106:: with SMTP id x6mr15587711ybx.364.1595613693923; Fri, 24 Jul 2020 11:01:33 -0700 (PDT)
MIME-Version: 1.0
References: <CALGR9obkGENj_Brk5D29Z6HB-yq9TbPLjUXSNbotAZJ0LRHgSg@mail.gmail.com> <CABcZeBMQNX_qbXT_qCmyWuXdLeL2=ar0u9yKB=c8M7=WNB4oVQ@mail.gmail.com> <1909E24B-73CC-4129-9B64-F0A3BE2D74D7@eggert.org> <CA+9kkMCRfhNayN5jM5g3Ckwst4GGxR++be5p7ea1jYkE3MbzqA@mail.gmail.com> <CABcZeBOcZd9=Th4T=rm0i+EGnG1i8bjembf20ungVYaDSpjusQ@mail.gmail.com> <7b5c104c-36b6-3fe1-4e5b-0e42cc9e2b36@huitema.net> <74ef5430-8e3f-4b6b-b81f-b25443e975b4@www.fastmail.com> <32c098c3-24e4-1d7c-fdf5-33761adacfa8@erg.abdn.ac.uk> <FA3E4F14-570C-4A28-A2C8-EA2B3937E614@eggert.org> <0ee0a444-3910-3e71-54aa-581431495648@erg.abdn.ac.uk> <3644F334-F148-4FF5-AE86-015C073871AC@eggert.org> <c28e05f6-637d-9183-11db-f8daa8b9e7c4@huitema.net> <CACpbDcc86pgVpcN7DHb2s8aRGjzCC4RNjYPnGyDHhUCWg-G9zA@mail.gmail.com> <337cd3d0841e9d94a034aa2402ac2a030af550f8.camel@ericsson.com>
In-Reply-To: <337cd3d0841e9d94a034aa2402ac2a030af550f8.camel@ericsson.com>
From: Ian Swett <ianswett@google.com>
Date: Fri, 24 Jul 2020 14:01:22 -0400
Message-ID: <CAKcm_gM73QaQ_eruoy7YNnrhUF_G+SNPzFxA99RF=m7yCa98Sw@mail.gmail.com>
Subject: Re: Consensus call for Late-Stage documents, pre-IETF 108 edition
To: Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org>
Cc: "huitema@huitema.net" <huitema@huitema.net>, "jri.ietf@gmail.com" <jri.ietf@gmail.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, "lars@eggert.org" <lars@eggert.org>, "quic@ietf.org" <quic@ietf.org>, "mt@lowentropy.net" <mt@lowentropy.net>
Content-Type: multipart/alternative; boundary="0000000000006d662805ab33c35d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/AEx5ooZouLC9VWqD5g_kt15aIug>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jul 2020 18:01:45 -0000

I'm happy with the direction of the PR.

I don't think it's possible to compare this to TCP, since in TCP if the NAT
hole is dropped, the connection is closed.

Magnus, I'm not sure change of attachment behind a CGN is very likely based
on where I've seen CGN deployed.  Also, it'd require migration from Wifi to
Wifi, which is a lot less common than Wifi to Cell or Cell to Wifi.  But
even so, two physically adjacent wireless networks on the same ISP probably
have more in common than not.

There's a very real cost to re-entering slow-start, not just in terms of
time, but also in terms of the packet loss and bufferbloat it tends to
cause.  Congestion controllers are virtually always sending at the wrong
rate, so this comes down to whether continuing with the existing estimates
are better than starting over.  In the case of a port change, I think it's
a very good bet that the existing estimates are better.

One additional note: Clients MUST change Connection ID if they
intentionally migrate, so a server can use the lack of CID change as a
signal that it was likely an NAT or other unintended path change.

Ian


On Fri, Jul 24, 2020 at 3:47 AM Magnus Westerlund <magnus.westerlund=
40ericsson.com@dmarc.ietf.org> wrote:

> Hi,
>
> So if I understand this correctly we have a couple of different reasons for
> reasons for the port change to occur.
>
> NAT binding times out: In this case the CC state should also have been
> aged as
> the QUIC connection has not sent anything for many seconds. I would think a
> minimal of 5 seconds, likely at least 30 seconds of inactivity for an
> established QUIC connection as it will have gotten the NAT into a
> bi-directional
> UDP flow state, rather than a one of request response state, like for NATs
> with
> DNS binding recovery optimizations.
>
> NAT binding lost in restart or crash of NAT device: In this case it is
> likely
> that an active connection have lost several packets on the old port before
> the
> migration happens. Will those losses be represented in the migrated CC
> state?
> An
> semi active connection may have not lost any packets and in worst case had
> a
> fairly large window, then went quite some few seconds will the NAT device
> recovers and thus a limited aging of CC state could have occurred.
>
> NAT lost binding to resource exhaustion: In case of an attack or simply
> overwhelming amounts of flows the NAT exhaust its resources and starts
> recycling
> the bindings that had longest time since last use. That could in worst case
> cause frequent rebindings. I would say this is broken NAT device that is
> better
> of refusing bindings in this scenario than making existing bindings
> breaking.
>
> Change of attachment point behind a CGNAT: A node could potentially change
> its
> local IP address but stay behind the same CGNAT. The NAT will create new
> binding
> as it doesn't know that this is the same device. This represents an actual
> path
> change. It doesn't appear the most likely scenario, but could occur for
> example
> if I move from my home wifi to my frindly neighbours wifi which I also
> attach
> and we use the same ISP.
>
> Does anyone have a scenario where a port change would actually occurr when
> the
> QUIC conenction is transmitting at any significnat rate and the port change
> would not incurr packet loss or seconds of the path being blocked?
>
> To me it appears that the scenarios I can think of all would result in
> significnat reduction of allowable transmission rate anyway. Have I missed
> something relevant here?
>
>
> Cheers
>
> Magnus Westerlund
>
>
> On Thu, 2020-07-23 at 14:02 -0700, Jana Iyengar wrote:
> > I'm happy with the resolution that Ted proposed and Lars wrote up in PR
> 3945.
> >
> > We should not forget that endpoints will do what they choose to do on
> this
> > particular issue. It's perfectly reasonable to assume that port changes
> are
> > infrequent and do not reflect a path change commonly. In the rare case
> that it
> > happens and in the rarer case that it is in fact a path change, both
> > congestion controllers and RTT estimators are adaptive. The text in the
> PR
> > captures this possibility. That reflects reality and is an adequately
> cautious
> > recommendation, IMO.
> >
> > On Thu, Jul 23, 2020 at 11:47 AM Christian Huitema <huitema@huitema.net>
> > wrote:
> > > On 7/23/2020 12:42 AM, Lars Eggert wrote:
> > > > Hi,
> > > >
> > > > On 2020-7-23, at 10:34, Gorry Fairhurst <gorry@erg.abdn.ac.uk>
> wrote:
> > > > > These methods often hash based on port, IP, and maybe other fields
> to
> > > > > select a queue - There are a finite set of queues, a rehash
> results in
> > > > > the traffic moving queue ... to chooses a different path or queue
> within
> > > > > the device. This mapping is statistical, this matters more if the
> > > > > multiplexing is low and a port change results in unbalance across
> > > > > quques/paths.
> > > >
> > > > I agree this is mostly a concern for low-mux'ing cases when a single
> > > > rehash can create significant imbalance. How common are such
> deployments,
> > > > and how much of a problem is such a temporary imbalance (the CC will
> > > > adjust quickly). Esp. compared to forcing slow-start after every NAT
> > > > rebind.
> > >
> > > Gorry, Lars, where can we find data on the NAT behavior and the
> relation
> > > between NAT rebinding and routing paths? In home routers, NAT rebinding
> > > typically only change if the session is quiet for some time. Do we
> observe a
> > > different behavior with CGNAT?
> > > -- Christian Huitema
> --
> Cheers
>
> Magnus Westerlund
>
>
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> <+46%2010%20714%2082%2087>
> Torshamnsgatan 23           | Mobile +46 73 0949079
> <+46%2073%20094%2090%2079>
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>
>