Re: http/2 initial limits - i see flow control initial limits specified, but not stream limits

William Chan (陈智昌) <willchan@chromium.org> Sat, 04 May 2013 02:05 UTC

Resent-Date: Sat, 04 May 2013 02:04:48 +0000
Resent-Message-Id: <E1UYRqC-0000ZL-Ei@frink.w3.org>
MIME-Version: 1.0
Sender: willchan@google.com
In-Reply-To: <CAP+FsNe8N33yJAthsHv_J8wU8WUESoGtcRkembCCJ8kQnNdRig@mail.gmail.com>
References: <CAA4WUYjnMupHPL8i13qzNTYr4dDjc_-ygZABaM1C6c8zUuMGJQ@mail.gmail.com> <CABP7RbfxGehBXw+114wyaKJaTQV1rLqCiZXq6KERWbO_HRRpBg@mail.gmail.com> <CAA4WUYg_zRcyU1Qju+MA_4YT3FJB4PVAWi+iVkqi=9uvAo84YA@mail.gmail.com> <CABP7RbdCWOQZRSmqTtc_X7qKnRi=vRBpQDH3PaZE42ZQbg--Jw@mail.gmail.com> <CAP+FsNesYysCpM60bEWBWk2_BzHpBtRUahck2K91TPX979GT1Q@mail.gmail.com> <CABkgnnW50TEaDoieOa3t3fSK7mCPECNzyZTSyQYD2ZqQKuznHA@mail.gmail.com> <CAP+FsNe8N33yJAthsHv_J8wU8WUESoGtcRkembCCJ8kQnNdRig@mail.gmail.com>
Date: Fri, 03 May 2013 23:04:11 -0300
Message-ID: <CAA4WUYicCQJUduw4i0G8MVpado_-m6b=jxcT=3f50d0rsTLFQQ@mail.gmail.com>
From: "William Chan (陈智昌)" <willchan@chromium.org>
To: Roberto Peon <grmocg@gmail.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, James M Snell <jasnell@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="047d7bf0de8837a97304dbdae234"
Received-SPF: pass client-ip=209.85.216.169; envelope-from=willchan@google.com; helo=mail-qc0-f169.google.com
Subject: Re: http/2 initial limits - i see flow control initial limits specified, but not stream limits
Archived-At: <http://www.w3.org/mid/CAA4WUYicCQJUduw4i0G8MVpado_-m6b=jxcT=3f50d0rsTLFQQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

It sounds like I misremembered the spec. Sorry folks :) Sounds like any
change here is blocked on issue #40.


On Fri, May 3, 2013 at 10:55 PM, Roberto Peon <grmocg@gmail.com> wrote:

> Yup, the language in the specs is the same as what is currently in the
> HTTP/2 spec, but people have been interpreting them differently (or at
> least I assume so).
>
>    - 4 - SETTINGS_MAX_CONCURRENT_STREAMS allows the sender to inform the
>    remote endpoint the maximum number of concurrent streams which it will
>    allow. By default there is no limit. For implementors it is recommended
>    that this value be no smaller than 100.
>
> is the thing in question, and most implementations that I know of default
> to 100, which makes sense given that "no limit" and "unlimited" are not
> always the same.
> -=R
>
>
> On Fri, May 3, 2013 at 3:46 PM, Martin Thomson <martin.thomson@gmail.com>wrote:
>
>> On 3 May 2013 14:22, Roberto Peon <grmocg@gmail.com> wrote:
>> > This does differ from SPDY,
>>
>> This doesn't differ from the SPDY we were given.
>>
>> > but (still) seems reasonable given the number of
>> > streams created in the initial RTT shouldn't be unbounded anyway.
>> > Assuming we have persisted settings (which is in doubt, I guess), this
>> would
>> > only be a problem for the first RTT in a session where we didn't have
>> the
>> > persisted setting.
>>
>> I think that this default is under contention still:
>> https://github.com/http2/http2-spec/issues/40
>>
>> We may ultimately determine that some value between 0 (what #40
>> proposes) and infinity (status quo) is more appropriate.
>>
>
>

http/2 initial limits - i see flow control initia… William Chan (陈智昌)
Re: http/2 initial limits - i see flow control in… James M Snell
Re: http/2 initial limits - i see flow control in… William Chan (陈智昌)
Re: http/2 initial limits - i see flow control in… James M Snell
Re: http/2 initial limits - i see flow control in… Roberto Peon
Re: http/2 initial limits - i see flow control in… Martin Thomson
Re: http/2 initial limits - i see flow control in… Roberto Peon
Re: http/2 initial limits - i see flow control in… William Chan (陈智昌)