Return-Path: X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5028821F99D0 for ; Wed, 24 Jul 2013 17:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHlrcSJVHKgf for ; Wed, 24 Jul 2013 17:59:34 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id E4D4F21F99CE for ; Wed, 24 Jul 2013 17:59:33 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from ) id 1V29ss-0005dN-Gb for ietf-http-wg-dist@listhub.w3.org; Thu, 25 Jul 2013 00:58:22 +0000 Resent-Date: Thu, 25 Jul 2013 00:58:22 +0000 Resent-Message-Id: Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1V29sj-0005cQ-I5 for ietf-http-wg@listhub.w3.org; Thu, 25 Jul 2013 00:58:13 +0000 Received: from mail-ob0-f171.google.com ([209.85.214.171]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from ) id 1V29si-0000mL-Rj for ietf-http-wg@w3.org; Thu, 25 Jul 2013 00:58:13 +0000 Received: by mail-ob0-f171.google.com with SMTP id tb18so149826obb.2 for ; Wed, 24 Jul 2013 17:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wEZ38DedgQrHdkXuMRB077Nr9UVi1JVFHSSb7ymz2Pg=; b=iGA0sVLNZ6xTw20WsKl8M9lNxsF57XSXNuJ8jUMt64EaHTWPoP1UDFk2mYWoz7//ZL 250f6DcGVSbCd9Xe4ve2KBZ+RKKwf2Snv5oE35z7DjfSmLJxF0CDdojgzVofYgmJcGD5 rQy+Vh06WAm6Gn5UcJtT0s05FHwxNkSZqdADhCCn+CdcJ8S9pak0p/RMWdGN3TVUrhN/ pSVVyRHv+YVHbNpa24azZSBXNUn1LGuGkWIodHhmtMEZgDeEMwFx0lQ0xjOCA2hay1VK 2O4BhUZB2NCbnPklJdzqQRAv4qvj7Xdz7Hum1o4wBZPI8DfAInaqBM2NWtknD4ixOlZJ ND1g== MIME-Version: 1.0 X-Received: by 10.42.62.4 with SMTP id w4mr3726155ich.27.1374713866831; Wed, 24 Jul 2013 17:57:46 -0700 (PDT) Received: by 10.64.32.103 with HTTP; Wed, 24 Jul 2013 17:57:46 -0700 (PDT) Received: by 10.64.32.103 with HTTP; Wed, 24 Jul 2013 17:57:46 -0700 (PDT) In-Reply-To: References: Date: Thu, 25 Jul 2013 09:57:46 +0900 Message-ID: From: Tatsuhiro Tsujikawa To: "Kulkarni, Saurabh" Cc: ietf-http-wg@w3.org, Patrick McManus Content-Type: multipart/alternative; boundary=90e6ba613cfab34c5504e24b839f Received-SPF: pass client-ip=209.85.214.171; envelope-from=tatsuhiro.t@gmail.com; helo=mail-ob0-f171.google.com X-W3C-Hub-Spam-Status: No, score=-3.4 X-W3C-Hub-Spam-Report: AWL=-2.618, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1V29si-0000mL-Rj 3cd983261af3bf6a8a647fb6edd9bc03 X-Original-To: ietf-http-wg@w3.org Subject: Re: END_FLOW_CONTROL for particular stream interpretation Archived-At: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/18907 X-Loop: ietf-http-wg@w3.org Resent-Sender: ietf-http-wg-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: --90e6ba613cfab34c5504e24b839f Content-Type: text/plain; charset=ISO-8859-1 2013/07/25 8:22 "Kulkarni, Saurabh" : > > Conversely any WINDOW_UPDATE frames for individual streams (stream_id: non zero) need to be rejected when connection level flow control is turned OFF, right?. (Either by WINDOW_UPDATE with END_FLOW_CONTROL bit set for stream_id:0 or by SETTINGS_FLOW_CONTROL_OPTIONS). > My understanding is that: If SETTINGS_FLOW_CONTROL_OPTIONS with 0x1 is sent, both connection and stream level flow control are disabled, so yes, it can be rejected. But only with WINDOW_UPDATE with stream id 0 and END_FLOW_CONTROL flag, it only disables connection level flow control and stream level flow control is still alive unless it is turned off individualy. Best regards, Tatsuhiro Tsujikawa > - Saurabh > > From: Patrick McManus > Date: Wednesday, July 24, 2013 4:16 PM > To: Saurabh Kulkarni > Cc: HTTP Working Group > Subject: Re: END_FLOW_CONTROL for particular stream interpretation > > I believe the session window is still in effect as usual.. so normally the max-send is min(stream-window, session-window) and after the window-update, at least when sending on stream 2 in your example, it is simply session-window. > > > On Wed, Jul 24, 2013 at 7:01 PM, Kulkarni, Saurabh wrote: >> >> What happens to session level flow control when a WINDOW_UPDATE frame with END_FLOW_CONTROL flag set is received with a particular stream id (stream_id other than "0")? >> >> E.g. >> Session Window Size: 64kb >> Stream Window Size: 64kb, stream_id: 2 >> Receive WINDOW_UPDATE with END_FLOW_CONTROL bit set, stream_id:2 >> >> Should the sender follow the session level flow control or ignore flow control for stream_id:2? >> >> - Saurabh > > --90e6ba613cfab34c5504e24b839f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


2013/07/25 8:22 "Kulkarni, Saurabh" <sakulkar@akamai.com>:
>
> Conversely any WINDOW_UPDATE frames for individual streams (stream_id:= non zero) need to be rejected when connection level flow control is turned= OFF, right?. (Either by=A0WINDOW_UPDATE with END_FLOW_CONTROL bit set for = stream_id:0 or by SETTINGS_FLOW_CONTROL_OPTIONS).
>

My understanding is that:

If SETTINGS_FLOW_CONTROL_OPTIONS with 0x1 is sent, both conn= ection and stream level flow control are disabled, so yes, it can be reject= ed.
But only with WINDOW_UPDATE with stream id 0 and END_FLOW_CONTROL flag, it = only disables connection level flow control and stream level flow control i= s still alive unless it is turned off individualy.

Best regards,

Tatsuhiro Tsujikawa

> - Saurabh
>
> From: Patrick McManus <pmcm= anus@mozilla.com>
> Date: Wednesday, July 24, 2013 4:16 PM
> To: Saurabh Kulkarni <sakulk= ar@akamai.com>
> Cc: HTTP Working Group <ietf= -http-wg@w3.org>
> Subject: Re: END_FLOW_CONTROL for particular stream interpretation
>
> I believe the session window is still in effect as usual.. so normally= the max-send is min(stream-window, session-window) and after the window-up= date, at least when sending on stream 2 in your example, it is simply sessi= on-window.
>
>
> On Wed, Jul 24, 2013 at 7:01 PM, Kulkarni, Saurabh <sakulkar@akamai.com> wrote:
>>
>> What happens to session level flow control when a=A0WINDOW_UPDATE = frame with END_FLOW_CONTROL flag set is received with a particular stream i= d (stream_id other than "0")?
>>
>> E.g.
>> Session Window Size: 64kb
>> Stream Window Size: 64kb, stream_id: 2
>> Receive WINDOW_UPDATE =A0with END_FLOW_CONTROL bit set, stream_id:= 2
>>
>> Should the sender follow the session level flow control or ignore = flow control for stream_id:2?
>>
>> - Saurabh
>
>

--90e6ba613cfab34c5504e24b839f--