Re: Comments on QUIC transport - draft-ietf-quic-transport-20
Jana Iyengar <jri.ietf@gmail.com> Thu, 25 April 2019 00:55 UTC
Return-Path: <jri.ietf@gmail.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 5290A12026E for <quic@ietfa.amsl.com>; Wed, 24 Apr 2019 17:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_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 F57GbkGn8W2b for <quic@ietfa.amsl.com>; Wed, 24 Apr 2019 17:55:18 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 1FF641201D4 for <quic@ietf.org>; Wed, 24 Apr 2019 17:55:18 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id j11so16144624lfm.0 for <quic@ietf.org>; Wed, 24 Apr 2019 17:55:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hQneddQJDhDOkcrjwR6s08cocME574J4mW4gjKKf+es=; b=ZfFhoynuaVOjtufphFzjX0yRzKPfPmUoinRg4uc7nprIqlAdwW4LO73uwpC4rdI7az zRxJTd5CEyaoGmmnMNK7TBKXgE3RU8bfqmbkYIY0aOlvvj2rrI4rlFljS5szStOH+fpZ RNS3unL8N9KRQLecC7Tl6EWceJwl9Kxg1nsYoLCBnhe+EId4VUPhiOmcN1GEbwahWE0S 4fbvv88R4eWAwa0fYzjBQ9hQpkaj7wPDhSxWG6GQcSosmPUHkUMMtl6iOWR3ZGAqEgxn n6t9Qo3yKCoFmX1eDp9hhLMrHkNs0LBekBIWx6tfpYQNIslV+l5V/1Hrzaoe2dy+jZzC oyxg==
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=hQneddQJDhDOkcrjwR6s08cocME574J4mW4gjKKf+es=; b=Xs6vr0IwcG7gtil/gcNYODFPBF/tCBxVtIJVFPrrho91OKcXty8J3S4TLqwAB39kL1 W0tiux5+gIDvN9zEyzjEEkuJ5F+CVEGRon5FySWyKAanv52yOXGKjzKgonRtqAkcfu8/ wiPZhTJrALUwl4YMUkHsQxxFa34N5JdHY4tbf8Wy9kn8E2XbeM7+QwIdnwxGYeh6sZpA FXnYrczyE1bhGjxvJ56SgKGgqpom06Zis772lqkBPZSbMU7OLQySgNuLZQUFZgwq/TZ4 d5ZQHalTuUjpvSxYx/s2KyrTx+wRZd5LEVTXhSh8aINBrKoRb7cyE0YPEYWgBIBlVlgf P+bw==
X-Gm-Message-State: APjAAAUudfIs4w6OxZA/wF/b1eZMpzRMobzV3Pz/yZYsfAFShDTm5U+e DjR57EGZHnHvqLWzR146UPkU9rr7nzYyj/ITlrjkc2nL
X-Google-Smtp-Source: APXvYqws2yL9/5u88W8X2OKGSrWEAnyMISAzjSGY9KufJGs0g0JImCCBuXGO6vC831fcxAQpuGPTI3t/ZJ51UFalNkA=
X-Received: by 2002:a19:c38d:: with SMTP id t135mr18826894lff.164.1556153716131; Wed, 24 Apr 2019 17:55:16 -0700 (PDT)
MIME-Version: 1.0
References: <CAN1APdeuZUeb0ZBxAKfQiOqp3qRf8dWZevMkrxD0oC0e9JGt9w@mail.gmail.com> <CAN1APdcSrzRY_mzTcncVrnn0cDENFPe88eySh=Q-hEJ+jG0MXw@mail.gmail.com> <2613919B-5463-4AB8-8A9D-56AA11E8362E@trammell.ch> <5CC02DD5.3040102@erg.abdn.ac.uk>
In-Reply-To: <5CC02DD5.3040102@erg.abdn.ac.uk>
From: Jana Iyengar <jri.ietf@gmail.com>
Date: Thu, 25 Apr 2019 09:55:05 +0900
Message-ID: <CACpbDcdXdY0H-kvdxqtgx-NeGkY4jkEt01_s=K9Emk6ifPSnXA@mail.gmail.com>
Subject: Re: Comments on QUIC transport - draft-ietf-quic-transport-20
To: gorry@erg.abdn.ac.uk
Cc: QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000774ae90587504589"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/alCUV5wto8_8WtWfIta0FCFwkc4>
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: Thu, 25 Apr 2019 00:55:21 -0000
Thanks for your detailed read, Gorry, will respond soon. On Wed, Apr 24, 2019 at 6:35 PM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote: > > I have just read QUIC transport, prior to doing a detailed read of the > congestion control spec) and have a number of comments on the text and > one more involved question on the decision on what to do with congestion > control when there is a path change. I 'll send the latter issue later. > (The editors can break these up into issues in the git if this seems > useful to them). > > Gorry > > ————— > The following comments/questions mainly relate to text: > — > NiT: Section 4: > “ It is necessary to limit the amount of data that a receiver could > buffer,” > - Is this correct? (i.e. do we wish to limit what it can do or what it > needs to buffer - is this a maximum limit or a minimal requirement? (I > suspect the latter). > --- > Question: Section 4: > “The implementation SHOULD provide an interface to QUIC to tell it > about its buffering limits so that there is not excessive buffering > at multiple layers.” > - This seems an odd place to me to make a subtle new requirement on the > IP-layer/interface: This lower-layer implementation interface > requirement is buried in the spec. This seems that it could go > unnoticed, and isn’t really a requirement of the protocol, but of the > layer below. > — > Nit: Section 4: > “that the sender receives an update before running out of flow control > credit, even if one of the packets is lost.” > - the requirement could be misread as ONLY one packet is lost, whereas I > think it means if one or more packets are lost. > — > Nit: Section 4: > “That is, once a receiver > advertises an offset, it MAY advertise a smaller offset, but this has > no effect.” > - No effect on what? - presumably something at the sender? > — > Nit: Section 4: > “Implementations might choose to increase limits as > streams close to keep the number of streams available to peers > roughly consistent.” > - could this be changed to “are closed” or something to avoid misreading > of the word “close”. > — > NiT: Section 5: > “A Version Negotiation (Section 17.2.1) packet echoes the connection > IDs selected by the client, both to ensure correct routing “: > - not strictly routing? Isn’t this “forwarding”. (The word routing is > used again in the section and in section 7.2 > — > Section 5: > NiT: “different IP or port” > - could you say: > “different IP address or transport port” > --- > Section 5.1.1: > NiT: “The connection > ID randomly selected by the client in the Initial packet and any > connection ID provided by a Retry packet are not assigned sequence > numbers unless a server opts to retain them as its initial connection > ID.” > - could this sentence be simplified, it is hard to parse and long. (Or > insert a comma) > — > Section 5.2: > NiT: “ or - for servers -“ > - what is the meaning of the minus signs? does it imply “particularly” > or “only”, I was unsure. > — > Section 5.2.1: > Nit: “Packets that don't match an existing connection are discarded.” > - can we remove “don’t” and explain what does match? > - Is this something like: “Packets with a Connection ID that does not > match an existing > connection are discarded.” > --- > Section 5.2.1: > Nit: “Due to packet reordering or loss, clients might receive packets for a > connection that are encrypted with a key it has not yet computed.” > “ > - Is it possible to say something like: “Packet reordering or loss, > might cause a client to receive packets for a connection that were > encrypted with a key that it has not yet computed.” > — > Section 8.1.2: > - The title seems a little odd to me? Future? > — > Section 9.3.3.: > ?: “ An off-path attacker that can observe packets might forward copies of > genuine packets to endpoints. “ > - This may make total sense to some people, but to me an “off path” > observer has no access to the data on the path. Maybe someone could work > this text in a way that doesn’t cause this confusion. > — > Section 9.3.3.: > NiT: “If the copied packet arrives before > the genuine packet, this will appear as a NAT rebinding.” > I think the pathology is the same as a NAT rebinding, but it isn’t one. > The text could be clear that this appears as if there had been a NAT > rebidding? > — > Section 9.3.3.: > ?: “The attack is more reliable “ > - The term reliable does have certain implications in transport > documents, if this isn’t intended could this phrased as a higher > likelihood of success or something like that? > - similarly “attack is reliably faster “ > - explain how the path can be reliable, or please choose another word? > — > Issue: Section 10.4.2.: > ?" “using a second iteration of a preimage-resistant function. > - Maybe I am alone, but I did not understand what was intended by this, > and where this was defined: is this I-D: > --- > Section 19.1: > Question: “Padding can be used to > increase an initial client packet to the minimum required size, or to > provide protection against traffic analysis for protected packets.” > - I suggest this also can be used to perform path packet probing in > DPLPMTUD, and the text should somehow be improved to permit this. > — > Section 9.4: > “The capacity available on the new path might not be the same as the > old path.” > - I disagree in the words here, because I think the normal IETF > transport assumption is much stronger than “might”, and the draft should > say something like: > “The endpoint should not assume the capacity available on the new path > isbe the same as the > old path.” > — > Section 9.4: > NiT: “On confirming a peer's ownership of its new address, an endpoint > SHOULD immediately reset the congestion controller and round-trip > time estimator for the new path.” > - To be clear, does this reset require setting the CC to the initial > value for a connection? > — > RFC2119: “A sender can make exceptions for probe packets” > - Is that “MAY” - that would seem entirely reasonable. > — > “ While multiple paths might be used during connection migration, a > single congestion control context and a single loss recovery context > (as described in [QUIC-RECOVERY]) may be adequate. “ > - I think the present I-D should not make these claims, because this > seems like a CC decision. I actually do not understand this specific > claim as currently presented. > — > Section 9.7: > Ref: “The IPv6 flow label SHOULD be a pseudo-random function of the source > and destination addresses, source and destination UDP ports, and the > destination CID. “ > - Please cite RFC3976 (which contains details on how to set flow labels).— > — > Section 12.3: > NiT: “and acknowledged in packets which are also Initial packets” > - Change /which/ to /that/. > — > Section 14.2: > Ref: “An endpoint MUST NOT increase PMTU based on ICMP messages.” > - please add citation to [RFC1191] [RFC8201], so the reader knows this > is true of any protocol. > — > Section 21.2: > Question: “ Once a connection is established QUIC endpoints might > accept some > unauthenticated ICMP packets (see Section 14.2), but the use of these > packets is extremely limited. “ > - Why is this a good idea, please explain what these would be used for? > — > Section 21.5: > “ An adversarial sender might intentionally send fragments of stream > data in order to cause disproportionate receive buffer memory > commitment and/or creation of a large and inefficient data structure.” > - Is this memory commitment at the target? (I assume so, but it would be > easier to read if it said this). > - > > >
- PROXY protocol Mikkel Fahnøe Jørgensen
- Re: PROXY protocol Mikkel Fahnøe Jørgensen
- Re: PROXY protocol Willy Tarreau
- Re: PROXY protocol Brian Trammell (IETF)
- Re: PROXY protocol Willy Tarreau
- Re: PROXY protocol Mikkel Fahnøe Jørgensen
- Re: PROXY protocol Mikkel Fahnøe Jørgensen
- Comments on QUIC transport - draft-ietf-quic-tran… Gorry Fairhurst
- Re: Comments on QUIC transport - draft-ietf-quic-… Jana Iyengar
- Re: PROXY protocol Martin Duke