Re: http/2 prioritization/fairness bug with proxies

I'm happy to see that like what happened in the other thread, lots of the
disagreement ultimately was due to confusion over what was actually being
discussed. For prioritization, let's remember that we are discussing the
stream prioritization mechanism as described in the draft spec (
http://htmlpreview.github.com/?https://github.com/http2/http2-spec/blob/master/draft-ietf-httpbis-http2.html#StreamPriority)
which expresses the order in which the client advises the server to service
streams.

As before, I'd like to reiterate (and I believe most people have agreed
here) that we should not use receive windows to achieve prioritization.

Nico, I think the discussion of whether or not HTTP/2 stream prioritization
is useful for different traffic classes is a useful discussion to have. I
suggest starting a separate thread, so we don't incorrectly conflate it
with the stream prioritization issue I raised here.

On Mon, Feb 18, 2013 at 6:07 PM, Nico Williams <nico@cryptonector.com>wrote:

> On Thu, Feb 14, 2013 at 3:42 PM, Roberto Peon <grmocg@gmail.com> wrote:
> > On Thu, Feb 14, 2013 at 12:26 PM, Nico Williams <nico@cryptonector.com>
> > wrote:
> >> But it's possible that we're talking about different thing.  One thing
> >> is priority for server processing of requests.  Another is for proxies
> >> -- here we have to start worrying about the multiplexing issues that
> >> SSHv1 and SSHv2 have had, and since I think we ware talking about
> >> proxies I keep coming back to these issues.
> >
> > Priority and flow control are separate issues.
> > Priorities are an expression of the order in which the browser
> wants/needs
> > resources.
>
> Ah, if that's all priorities do, then there's no issue.  However, if
> they relate to traffic classes (bulk vs. non-bulk) then we have the
> SSH problems.
>
> > Flow control is for receivers which are memory constrained to be sure
> that
> > they won't overrun memory requirements.
>
> It's for sinks that are slow.  All receivers are memory constrained, after
> all.
>

Correct, although browsers typically are less concerned than servers. But
that's generally because their sinks (CPU processing) are generally faster
than the sources (network) for HTTP traffic.


>
> >> > From an implementation standpoint: I'm already running out of
> ephemeral
> >> > port
> >> > space. I *do Not* want to use more connections.
> >>
> >> It's certainly what browsers do already, and have for many years.
> >> What's the problem?
> >
> > Browsers do this because HTTP effectively limits you to one outstanding
> > request per connection, which is effectively one request per RTT per
> > connection.
>
> Pipelining allows multiple requests to be sent before responses are
> written back.  The problem is that responses must be written in the
> same order as the requests.  The solution to that would be to add an
> XID (like basically any RPC protocol would, e.g., ONC RPC).


> > Allowing a larger concurrency per connection than 1 is what the
> multiplexing
> > does.
>
> I suspect that's not the only reason that browsers make multiple
> concurrent connections to servers.  To be fair, the SSH problems can't
> the reason either.
>

As a browser vendor, I can say that the primary reason to use multiple
connections is to achieve parallelization without head of line blocking. A
downside of multiple connections is increased contention (primarily
bandwidth) which can definitely slow down page load. We currently do not do
anything smart with regard to bulk transfers (like downloads). It's
possible we could try to use TCP receive windows to control this, but I'd
rather not go there as it's difficult to get right. I know that Patrick has
expressed interest in dabbling here for Firefox, so I guess this is one of
those situations where I'm more conservative than he. I look forward to him
gathering results first :)


> > Browsers are most often not the ones likely to run out of ephemeral port
> > space-- that is a problem for proxies and servers.
>
> Ah!  This is a good thing to point out.  But note that proxies are in
> a decent position to know if SCTP can work (namely, they can cache
> which servers it's worked for and which it hasn't).  So an SCTP
> binding of HTTP might still be useful.
>

Alternative transports may indeed be useful. But let's focus on TCP for
now, and just keep other possible transports in mind, as per the charter.


>
> >> > From an implementation standpoint: It is often impossible to figure
> out
> >> > that
> >> > k connections belong to a single client at all loadbalancers without
> >> > sacrificing orders of magnitude of performance. Orders of magnitude,
> not
> >> > just a factor of X.
> >>
> >> But I'm not saying you need to do that.  Nor am I implying it.
> >
> > If there are multiple connections, then the cost of coordination for this
> > kind of loadbalancing at large sites is orders of magnitude higher.
> > You're telling me that you wish to use multiple connections. Unless my
> > statement above is a lie, it must then follow that it will cost orders of
> > magnitude more for the same coordination.
>
> I'm telling you that if SSH multiplexing/flow control issues arise
> then the best solution is to have two TCP connections: one for bulk,
> and one for non-bulk.  Bulk/not-bulk adds a single boolean input to
> the routing process.  I don't see how that raises the cost of load
> balancing by one order of magnitude, much less two, not unless issues
> like scarcity of ephemeral ports are the root cause (load balancers
> are unlikely to have this problem, but proxies are).
>

I think the discussion of what mechanism to utilize to address different
traffic classes is a good one to have, but should be done in a separate
thread.


>
> >> > Browsers have used multiple connections because of limitations in
> HTTP,
> >> > which we're already solving with multiplexing.
> >>
> >> I strongly suspect that you're not solving them.  It's not just "oh,
> >> let's multiplex".  You need to watch out for the issues other
> >> protocols that multiplex different flows on single TCP flows have had.
> >>  You haven't demonstrated a grasp of those issues.
> >
> >
> > Nico, I've been working closely with browser folks for quite a while
> (years)
> > and have a good grounding in what is suboptimal today, after all, SPDY
> > started as a project with a server/proxy developer (me) and a browser
> > developer (Mike Belshe).
>
> You're right, I did not express myself very well.  I apologize.  I am
> concerned with any notion of flow control layered above TCP.  I'm not
> as concerned about priorities now that I understand their purpose (I
> did suspect we might be talking about different things.)
>

If you have concerns about the flow control proposal, please respond to
them there.
http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/0714.html is
the current thread on the topic.


>
> Nico
> --
>
>