Re: [squid-users] Delay Pool metered by requests/second ?

Please set your mailer to wrap lines. Around 72 is usually good.

On 14/06/11 02:29, Russell M. Allen wrote:
>
> Is it possible to configure Squid to delay delivery of the http
> response, without constraining the transmission rate? I think this
> is effectively a Delay Pool which meters by requests per second
> instead of Bytes per second.
>
> For example, client A is watching a streaming video, and as a result
> he is making a series of serial http requests for byte offsets in the
> target resource. Each request happens to corresponds to 10 seconds
> of video, but the number of bytes composing that 10 second chunk
> varies due to compression within the video. (That's why we can't use
> byte based metering.) * t0 - the first request arrives, is proxied
> to origin server, and response is ready. * t0 - the response is sent
> immediately since this is the first request in the 'pool'. Response
> begins at t0 and completes at t1. 450kB sent at 450kB/s. * t1 -
> second request received, is proxied to origin server, and response is
> ready. * t1 - response is placed into delay pool for 9 seconds
> (assume pool configured at 1 request/10 seconds) because the last
> request was at t0, so next request can't return until t10. * t10 -
> second request is responded to, beginning at t10 and ending at t12.
> 1 MB sent at 500 kB/s. * t15 - Third request, proxied to origin,
> response ready. * t15 - response put into delay pool until t20.
> (last request time + configured delay) * t20 - response sent. 750 kB
> at 3 MB/s. Response completes at t20.25.
>
> The objective is to control delivery of streaming media on the server
> side so that we deliver just in time to maintain a continuous
> playback. We do not want to deliver faster because we are billing
> for content watched. Normal streaming clients will buffer greedily,
> and we cannot determine seconds watched vs. seconds buffered.
>
> While the existing delay pool seemed appealing at first, the variable
> bitrate nature of the responses makes it impossible to limit based on
> bytes/second. Additionally, the clients are measuring the reply
> transmission rate (size of response over time between first byte and
> last byte of response) and using that as the driver for video quality
> decisions (ie, given enough bandwidth, the client will upgrade to a
> higher bitrate of the video... "adaptive streaming".) Thus, we
> cannot artificially constrain the clients bandwidth.
>
>
> I would love to hear some thoughts from the experts. Is this
> possible to configure or will it require development? If
> development, then can anyone give me a shot in the dark guess about
> the level of effort? Am I looking in the wrong place / Is this best
> solved another other way?
>
> Thank you for your time and dedication!! -Russell Allen

Yes it is possible to configure this. An external_acl_type helper that
pauses for your desired delay period before OK'ing the request will do
exactly that. If you find this works and need it more efficient an ACL
for Squid-3 will not be hard to create.

You may also want to look at chunked encoding on a long-polled
connection. The middleware and server will inform you up front with a
100-continue response if chunked is available end-to-end or not.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.12
   Beta testers wanted for 3.2.0.8 and 3.1.12.2