Re: [Spud] [QUIC] Network Path Requirements for QUIC
Jana Iyengar <jri@google.com> Sat, 18 June 2016 01:26 UTC
Return-Path: <jri@google.com>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E0D12DCC7 for <spud@ietfa.amsl.com>; Fri, 17 Jun 2016 18:26:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level:
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] 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 21MOX9bjPrnO for <spud@ietfa.amsl.com>; Fri, 17 Jun 2016 18:26:24 -0700 (PDT)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 6698912DCC2 for <spud@ietf.org>; Fri, 17 Jun 2016 18:26:21 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id w195so527654ywd.0 for <spud@ietf.org>; Fri, 17 Jun 2016 18:26:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w/wOn9xFRJxVX6EH9Nvp5EPfcodh5//rrVYn1tqc4jc=; b=K/MPywquGzyP7wcwFDVwj08315Cijb6CxlAJYJYyU1Rbv/nGIFQPpnwT5WWcOYz3D6 NX+uUXBqcOwoFMXNlzMUTNfA//B6bsXalhIMtbE6mK9ygJ/9plMttpfq9JnJS2ae2nsQ /89GDLxZwLznqi8o5aB0+QfgqirWA/eC6fJKUaRF/lXKg7AM4eUIJcn0O0nlWMBLBFkx dp/xBw0LHr6Dw44sGxmBP5inmyTtXpcgJQhMhQA9udtZcLpPXQuHcGZ7Ak2NFJbV6QuG issk0+C/2+QJK5gXbz9EGwvB9AdeOKocNyeY83xkaQI701hlbouXLojP5OUSyriENk98 RgVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=w/wOn9xFRJxVX6EH9Nvp5EPfcodh5//rrVYn1tqc4jc=; b=NPTsIFQaPhCaZ7wUNoYenojA97uI/sziSxy5eB9ts59tlN4AsZJbkWtJNs+y/ImADf W7cgFEU385wKL1sKPhXr3ZJ1SwQXCbxTjhjMfaWn6wpXRUxdRJ/BIEFhS7TGQWINh/Z/ M6miV0pUqpUvMBhGgxxlt8pus0JLwosEdJkJA3eE/evG0Joe63LF6rWcIjd2Y6fRf7v0 P7e5AJim5YWmLTGsWQdkIi3SzJkOF70aS/RrjU8AshGunxaNWx3jpduWzRma5vl3rqC4 7XGLDEfgQ0kn4n5kMV6r+ZtbZIPW6Tc33v9nos7JnSp+3GSBFv605qCWcNDM/FYXy3x0 /1OA==
X-Gm-Message-State: ALyK8tJW15Wfc2wOI0/xGczI2d+K4IG/FWm1jjvzpK1SJnAwZquQhNq91N4j5pIFLlhj+Gdp3ac2JetmJT6Y4Q0C
X-Received: by 10.13.210.67 with SMTP id u64mr2913222ywd.42.1466213180304; Fri, 17 Jun 2016 18:26:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.219.83 with HTTP; Fri, 17 Jun 2016 18:26:19 -0700 (PDT)
In-Reply-To: <27E99769-77F1-4F61-B7FD-31AFF3866F68@trammell.ch>
References: <D8376C9E-FD28-4FE3-B40A-D2BD58D2B4B7@cisco.com> <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> <DM2PR0301MB0655F1B2DC19EC23BEA36BE4A8540@DM2PR0301MB0655.namprd03.prod.outlook.com> <D96C08FC-916F-4130-9FEE-114264CA5FDA@cisco.com> <CA+9kkMDm0UYq71LVWRG9jFRy2Be-gmF16jvONusZNBhuDew0WQ@mail.gmail.com> <A61CC0ED-5FA5-47C9-AA3B-B3D429D7CA20@cisco.com> <CAGD1bZYSpXVoyUJwd=3oNVxRk1Agc=jjJiEr2wuH18FHhsx9hg@mail.gmail.com> <B9E3E345-235D-476C-8079-4E5AB0564A9E@cisco.com> <CAGD1bZa1DODT4hSOogeVLwd_vc__ydX82tcTTRqA3fhSMPuDOA@mail.gmail.com> <27E99769-77F1-4F61-B7FD-31AFF3866F68@trammell.ch>
From: Jana Iyengar <jri@google.com>
Date: Fri, 17 Jun 2016 18:26:19 -0700
Message-ID: <CAGD1bZZbPk7F7dqHYUaPF78DuxPzDiBwQ4nvP0dXL1+XOvm8JQ@mail.gmail.com>
To: Brian Trammell <ietf@trammell.ch>
Content-Type: multipart/alternative; boundary="001a114e7e30c75be90535835b5f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/uuN5E3Qqo6q2NAMsURjcv97JwcY>
Cc: Ted Hardie <ted.ietf@gmail.com>, 🔓Dan Wing <dwing@cisco.com>, Joe Hildebrand <jhildebr@cisco.com>, spud <spud@ietf.org>, Christian Huitema <huitema@microsoft.com>, "quic@ietf.org" <quic@ietf.org>
Subject: Re: [Spud] [QUIC] Network Path Requirements for QUIC
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Jun 2016 01:26:27 -0000
On Thu, Jun 16, 2016 at 2:12 AM, Brian Trammell <ietf@trammell.ch> wrote: > hi Jana, all, > > (adding spud@ietf.org) > > On one point, below: > > > On 16 Jun 2016, at 03:41, Jana Iyengar <jri@google.com> wrote: > > > > Hi Dan, > > > >> draft-wing-quic-network-req tries to up-level its recommendations by > saying 'we need consent' rather than suggesting how to achieve it. Consent > could be achieved in probably 3 or 4 different ways, and we need a > technique that works with multicast QUIC and with persistent QUIC > connections. It's up to WG to agree consent is > >> necessary, then to agree how to accomplish consent. We have identified > other things that impact the network and need discussion in the working > group (some small, some larger): Should the network clear its state > immediately after QUIC public reset, set timer, wait for a little while. > Is the network's sole identification the QUIC version in the > client-initiated connection, and can we avoid the network treating that > specially (which will be good and bad, I am remembering network treatment > of IKE's UDP 500 and 4500). If QUIC endpoint sends or receives many bogus > QUIC packets, how can network help stop or rate limit those, to defend the > links and defend other hosts on that network. If path drops state due to a > timeout (or crash, or software update, or whatever), how should the > endpoints learn and how should they react. Those previous things are > discussed in the I-D. In addition, QUIC complicates network diagnostics > and measurements, as well, which will be added in a later version of the > I-D. > > > > I understand what the draft describes, and as I said, I think this is > useful when the wg is discussing what is visible in the QUIC header and > what isn't. The wg can decide whether to care about a particular middlebox > function or not. > > > > That said, I think this may be one of our core disagreements: absent > agreement on what middlebox functions are essential, it's hard to argue how > QUIC should solve for them. We saw a very similar conversation play out in > MPTCP. There were many questions about how legacy middleboxes would treat > MPTCP options and modifications to TCP header bits. The problem was that > there were too many boogeymen middleboxes out there, and it was usually > anybody's guess how important any one particular behavior was. There was > small-scale measurement work done that helped direct the conversation, but > this is tricky territory -- tricky largely because of the lack of > substantial data about particular middlebox behaviors and their prevalence > and importance. > > > > In terms of how these apply to QUIC, we have data from the current > deployment of QUIC, and that can hopefully be brought to bear on the > decisions in the working group. Beyond that, I think it's all thin ice. We > can certainly try and get consensus on specific middlebox behaviors as > important, but that conversation is more general than just QUIC, and since > your draft is precisely such a list, I'd argue that it probably belongs in > PLUS, TSVAREA/TSVWG, or INTAREA. > > PLUS BoF proponent hat on: I think there is a point here that might make > sense to add to the PLUS draft charter that would naturally feed into QUIC: > > - Define a view of "essential middlebox functions", and a description of > the information from endpoints required to drive them. > > As you say, part of the problem is there is no agreement on either of > these questions. A focused discussion here could hopefully come to some > consensus. QUIC isn't really the place for this IMO, since the answer is > bigger than one instance of a new protocol over UDP. I'm not sure a general > INTAREA/TSVAREA activity would have the right focus, and I'm not sure it's > really in scope for TSVWG. > > draft-wing-quic-network-req looks to me (slightly rearranged and with the > QUIC-specific language stripped out) as a candidate document for this work > item. It's alsouseful input to the engineering work on a universal shim > protocol we intend to do in PLUS. (And as a bonus, if both QUIC and PLUS > are working from a common, defined view of what sort of functions are > essential, future integration between them won't be complicated by > differing architectural views). > +1. - jana
- Re: [Spud] [QUIC] Network Path Requirements for Q… Jana Iyengar
- Re: [Spud] [QUIC] Network Path Requirements for Q… Brian Trammell