Re: Framing and control-frame continuations

Since the client begins the connection with a SETTINGS frame, and
there is a setting "max_concurrent_streams" or whatever it's called
that indicates the max concurrent streams that the peer can initiate
(the limit is directional), the client can disable push if desired.
Likewise, receivers can control the about of data the sender can send
by using per-stream and per-session flow control windows (I'm cleaning
up the per-session text proposal and will send it out this weekend or
early next week). Of course, you want to make sure that a single
stream can utilize BDP, so you don't want to have the window sizes too
small, although it's debatable when or not you want a slow start
approach to ramping up a single stream's window up to BDP. All up to
the implementation, since you can send WINDOW_UPDATE deltas on a
per-stream basis and thus enable a single stream to reach BDP, yet
keep the initial window size for most streams small.

In short, I believe there are enough knobs for the receiver to prevent
"rude" sender behavior. I am more worried people will use them badly
and hurt performance.

On Wed, Feb 6, 2013 at 11:56 PM, Adrien W. de Croy <adrien@qbik.com> wrote:
>
>
> ------ Original Message ------
> From: "Patrick McManus" <pmcmanus@mozilla.com>
> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
> Cc: "Roberto Peon" <grmocg@gmail.com>; "Mark Nottingham" <mnot@mnot.net>;
> "HTTP Working Group" <ietf-http-wg@w3.org>
> Sent: 7/02/2013 8:31:38 p.m.
> Subject: Re: Framing and control-frame continuations
>
> <snip>
>
> unwanted server pushes.
>
> <snip>
>
> Sorry but I find the prospect of "unwanted" server pushes quite alarming.
> This phrase and a previous mail today which indicated that server push would
> be unilateral made me write this.
>
> Surely all server pushes should be solicited by the client first?  E.g. the
> client indicates it wants pushes.  Until it does that, it doesn't receive
> any.
>
> Having to choke them off seems like a bad choice.
>
> My gut tells me strongly the protocol should be "polite".  Neither end
> should ram anything significant (IOW "large") down the other end's throat
> without prior consent of the receiver (so this goes for large bodies on
> requests too).  Requests are deemed consent, so a server is entitled to
> respond.  Large request bodies are currently rude (unconsented) and it
> actually creates a lot of problems with auth.
>
> Adrien
>
>

Received on Thursday, 7 February 2013 08:06:36 UTC