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

Re: Priority straw man

From: Jeff Pinner <jpinner@twitter.com>
Date: Mon, 10 Feb 2014 10:52:50 -0800
Message-ID: <CA+pLO_injue+iKA+mrTT_fq2t-4bXcyHqiU+TjRTkKSop-u2UQ@mail.gmail.com>
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: (wrong string) ™ˆ™˜Œ) <willchan@chromium.org>, Peter Lepeska <bizzbyster@gmail.com>, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>, Osama Mazahir <OSAMAM@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Feb 10, 2014 at 10:36 AM, Mike Bishop

> Assuming I'm following correctly, Jeff's comments seem to reflect the tree
> model in Will's draft which had already been removed and isn't part of
> either proposal currently under discussion.  He would sent two unconnected
> chains of requests within a group, and expect them to be equally treated
> within that group's timeslice, regardless of the relative priorities of
> resources within each chain.  That's not possible with either proposal on
> the table currently, since as Martin notes the end results of both are
> equivalent.  The difference is strictly whether the collapsing of
> dependencies into a strict order happens on the client or server side of
> the connection.
Sorry I explained this poorly -- I meant the "(S1) <-- (S3, S5) <-- (S7)"
version as Martin put it.

> I'm curious about his comment that he would have to merge priority groups
> on the back-end, though -- unlike stream IDs, it's not like they're
> exhausted once used.  As soon as a group is empty, you can reclaim it for
> more streams and a different user.  Part of the bikeshed on the number of
> bits will certainly be how many simultaneously-active groups you need
> available on the back-end, but that's orthogonal to how priorities within a
> group are expressed.
I agree it's orthogonal. What I am trying to say is that with more streams
in a group than priority levels (which I believe is common -- even more so
if you collapse groups), it seems easier to proxy explicit dependencies
within streams than having to map them to group levels.

> I've been envisioning the scenario working like this:
>  - Server is allocating X% of back-end connection per user; user sends two
> groups with weights 80% and 20% on the front-end.
>  - On the back-end, proxy creates two corresponding groups, weighting them
> at 80%*X% and 20%*X%.
> This does require the proxy to reweight when one of the groups goes away
> -- and maybe even when the server doesn't have anything to send on one
> group -- if it wanted to maintain strict resource allocation across
> front-end connections; to deal with that, you would need groups-of-groups,
> or the ability to have disjoint lists of resources within a group which is
> essentially the same thing.  But then when you introduce multiple proxies
> on a path, the same problem shows up with another layer of indirection.
> To me, the key point is that this is advisory -- we need to get the server
> enough information to make smart decisions *when* there are decisions to be
> made, but not introduce so much extra state on the server that we slow
> things down in the aggregate.  It doesn't have to be perfect -- which is
> good, because it never will be.
I'm not nearly as concerned about the server case as the proxy case -- the
transmission of the priority state to the server has to be accurate enough
to not incentivize the client to play other games with dispatch order,
connections, etc.
Received on Monday, 10 February 2014 18:53:18 UTC

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