Re: [QUIC] Why not be explicit about Stream 3 flow control exception?

Jana Iyengar <jri@google.com> Tue, 29 November 2016 18:45 UTC

Return-Path: <jri@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 0CAFF129C24 for <quic@ietfa.amsl.com>; Tue, 29 Nov 2016 10:45:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.497
X-Spam-Level:
X-Spam-Status: No, score=-3.497 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_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, 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 4WTvcyRYxjmC for <quic@ietfa.amsl.com>; Tue, 29 Nov 2016 10:45:27 -0800 (PST)
Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 73152129649 for <quic@ietf.org>; Tue, 29 Nov 2016 10:45:27 -0800 (PST)
Received: by mail-ua0-x235.google.com with SMTP id 20so187994160uak.0 for <quic@ietf.org>; Tue, 29 Nov 2016 10:45:27 -0800 (PST)
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=lPV/I8+gl4MgzaYwVnkW+jwQGuyYsmzV0aCv1VOGNJM=; b=WtfQ6E/odP6GN1D64kb/0kMRlVwBZcY2nDtHY/OvE27IUtxyLZeanXsEDtC4ZXDaTu LAytCcIPhwhQlAsmEJ8M7L7nDm4DhRta8uhDUrccUY/eAKgBUtB9eJtL/wgqHHRLEhnD RfbJAIaJu2FOIxNsFqGcV5p0qymlOzxn9fijnz5jp+c0VcDl13j6rSAnzDgWh6CQL3MB JzJeKCm2CBMg/mKXTPsLqY7Ao7cvoNMBkXLeV0+k59krn3mCTWKQmP+0hdexuKI0fc/L hBPQWEn8+WPlmvrxP98A8BB8J/lFcHOChWKV3PlOBqPrU0SP5KDNYP/KieEow3Gumbu+ YKHQ==
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=lPV/I8+gl4MgzaYwVnkW+jwQGuyYsmzV0aCv1VOGNJM=; b=VVtWNMRj71TotTbfQ1lnGlUlg39du5aZhQX/uXVhTSYJlfgIFUK6Lk6AhVSSWGSV9K TYzEjoJEjG6tEJptJU0fcaa9jAtU0lkK0+bSrGfmkSMWM4aFeJLYI5VmurOJmBdEmoTW nqEJlnmrGLJ+7y3wQl4XtARCyOySg10Dd73UvaUjjgCS0Jk25F4xvAYuKVxwxDWOlbtD 8FpqlnF4Mg/ynduQcv3JcoADI3DXhoZkpxOem9XKr/OQGm7krqcSynVDILsxibjF57I1 ez/wPuzTyitDHICqtlNw77+A4seyOyXQUeKrP5VHzlF8qqSaVUNVoQvMqavfhlG/wDFN uGMA==
X-Gm-Message-State: AKaTC02+Zn4st6L9AmSftTz1MQ61e09aQdhHIjp9mdRbMZudtJ69O524EM2KxRPd0PeOOvAICkUV53FA3ZfC4vvo
X-Received: by 10.176.83.100 with SMTP id y33mr21145729uay.130.1480445126521; Tue, 29 Nov 2016 10:45:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.51.132 with HTTP; Tue, 29 Nov 2016 10:45:26 -0800 (PST)
In-Reply-To: <CAGudDpPfgQCWKXVv0v2B2MT8kkPnis2monE1ZGWRfHjyd_Tqmg@mail.gmail.com>
References: <CAGudDpPfgQCWKXVv0v2B2MT8kkPnis2monE1ZGWRfHjyd_Tqmg@mail.gmail.com>
From: Jana Iyengar <jri@google.com>
Date: Tue, 29 Nov 2016 10:45:26 -0800
Message-ID: <CAGD1bZYj3nTweFmBy4-XbvUkhhnqbwscb=q0HHtZkPrYrw0kVQ@mail.gmail.com>
Subject: Re: [QUIC] Why not be explicit about Stream 3 flow control exception?
To: "Aron ." <aron.schats@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c192480e08b86054274fd62"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/sMAr8cDiYSi7gImEaQmtBlx4EWk>
Cc: IETF QUIC WG <quic@ietf.org>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 29 Nov 2016 18:45:29 -0000

Hi Aron,

Apologies for getting to this late -- the IETF kept me busy.

[draft-hamilton-quic-transport-protocol-01] states (p. 35):
>
> o The crypto handshake stream, Stream 1, MUST NOT be subject to
> congestion control or connection-level flow control, but MUST be
> subject to stream-level flow control.
> o An application MAY exclude specific stream IDs from connection-level
> flow control. If so, these streams MUST NOT be subject to
> connection-level flow control.
>
> The second bullet point is obviously about Stream 3.  Seeing that there is
> no way(?) to negotiate which streams are to be excluded, why not spell out
> that Streams 1 and 3 are not subject to connection-level congestion control?
>

The second bullet point is about any application-chosen stream. An
application may choose to not exempt any stream if there are no special
streams.

This need not be negotiated on the wire, but can be known for any given
application. Specifically, the http-mapping draft is the document which, in
the current design, should say that stream 3 should be excluded from
connection-level flow control.

- jana