RE: Zero weight for 100 CONTINUE, instead of flow control

I'm also wondering how useful this would be in practice considering
that a user driven client could be loading viewing totally unrelated
sites son the zero weight transfer from site A would frequently still
flood the end user's network connection and conflict with use of site B.

I worked on a product a few years ago that was intended to improve the
user experience by giving priority to time critical transfers such as
VOIP. This product was to run in the end user's computer. The
fundamental flaw in the approach was that it had no view of the actual
traffic on the connection between the local network, shared by other
computers, an the network.

So I suspect such a feature wouldn't do much in general to improve
the user experience. Probably better would be a mechanism that allowed
the recipient to pace the transfer based on a bytes per second target.
At least some of the major video sites do this now to avoid sending
content the user will click away from in seconds.


On Wed, 2 Apr 2014, Mike Bishop wrote:

> I get the zero-weighted bulk download or video stream, where the client
> is basically saying that anything else it requests over the connection
> is more important.
>
> That feels like an odd semantic, though -- the weight of the group
> implies the client's suggestion to the server on how to prioritize
> resources.  Overloading it to also, in this instance, reflect the
> client's wish to know the server's suggestion for how *it* should
> allocate resources seems a little odd.
>
> Unless we're, in general, supporting that the server can send PRIORITY
> frames to the client to suggest how the client prioritize its uploads?
> I hope not, but maybe I missed that discussion.
>
> -----Original Message-----
> From: David Krauss [mailto:potswa@gmail.com]
> Sent: Tuesday, April 1, 2014 12:19 PM
> To: HTTP Working Group
> Subject: Zero weight for 100 CONTINUE, instead of flow control
>
>
> >> #436 Enable weight of 0.
> >>
> >> Not a lot of feedback here.  Potentially disruptive.
> >
> > ... and unless we see discussion on the list very soon, it's not going to make it into this implementation draft.
>
> Oh, I didn't know of the issue, but I was just going to ask about this!
>
> It's a better replacement for 100 CONTINUE than hacking flow control. (See my previous message, "Flow control protocol redundancy.")
>
> Sending a POST with a weight of 0 may notify a server that the sender is unsure whether to proceed. This matches the client-initiated semantic of waiting for CONTINUE.
>
> The disruption can be quite minimal, because a zero-weight condition need not be persistent. Say that an endpoint receiving a zero weight must respond with either a PRIORITY or a RST_STREAM.
>
> Unlike CONTINUE, this does not contort the protocol and rely on specific header processing. Default behavior to always resume the stream (for servers) or discontinue it (for clients) is reasonable for any ignorant application-level software.
>
> I really don't like the idea of using flow control to force the other end to stop. It does not offer appropriate guarantees, it relies on default settings, and it's a violation of network layering principles. Just as CONTINUE is too high-level for what it's supposed to do, flow control is too low-level.
>
>
>
>

Received on Wednesday, 2 April 2014 21:16:43 UTC