Re: Priority straw man

On Mon, Feb 10, 2014 at 10:36 AM, Mike Bishop
<Michael.Bishop@microsoft.com>wrote:

> 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.