W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: [Editorial Errata Reported] RFC7540 (4871)

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 1 Dec 2016 00:46:01 +1300
To: ietf-http-wg@w3.org
Message-ID: <ce140a63-d3c0-c65d-e567-a3846431ef74@treenet.co.nz>
On 30/11/2016 10:35 p.m., Martin Thomson wrote:
> On 30 November 2016 at 19:41, Cory Benfield wrote:
>> What happens if both stream A and B are blocked? Should my server endeavour to serve dependent streams in that case?
> 
> I guess so.  You don't want to completely stall out.  Obviously, if A
> and B have a parent with siblings that aren't blocked, then you
> continue there, but if everything is stalled, then I guess it's OK to
> make progress on any stream.
> 
> You could probably devise some sort of scheme where you pick the
> stream using some algorithm or other - maybe based on some best-fit
> criteria.  But I'd say that it doesn't matter at that point: if we
> assume that all streams that aren't blocked depend on blocked streams,
> then none of them will be useful to the other side until those blocked
> streams finish.  All you are doing is avoiding having a completely
> wasted connection.
> 

Well, not just that. You are also speeding up / making progress on the
non-blocked streams while waiting. The priority is a utopian/best-case
preference not a requirement.

The server should even deliver bytes of dependent streams if they have
bytes available, even if the A/B are not blocked but simply need less
bandwidth than is currently free in the send window.

Amos
Received on Wednesday, 30 November 2016 11:47:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 November 2016 11:47:07 UTC