W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Maintenance frame contention vs CONTINUATION

From: David Krauss <potswa@gmail.com>
Date: Tue, 22 Apr 2014 12:28:08 +0800
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Roberto Peon <grmocg@gmail.com>
Message-Id: <32B9E4FA-7C0E-4F29-966B-886C8C6E318D@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>

On 2014–04–22, at 12:13 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 21 April 2014 20:17, David Krauss <potswa@gmail.com> wrote:
>> The solution is to either schedule the entire block all at once, which perhaps imposes a size limit, or to be prepared for the priority inversion.
> 
> Correct, though it's entirely possible that you can't dump the entire
> block due to TCP window size constraints.

Various things break. The best strategy is to let the scheduler dictate an arbitrary upper limit, which might come from further down the network stack. After that, the client is stuck with priority inversion — it’s their fault anyway.

> No one claimed we were making HTTP perfect here, but I think that you
> will find that it's manageable with smaller sets of header fields.  

:) I’m just thinking in terms of limits that should be specified for my implementation. Right, there’s no problem, and “perfection” harming implementability would itself be a fault.
Received on Tuesday, 22 April 2014 04:28:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC