Re: Fragmentation for headers: why jumbo != continuation.

Hey Willy,

Roberto isn't making a latency argument -- it's an argument for minimal buffering in the optimistic case(s).

Cheers,


On 11 Jul 2014, at 3:01 pm, Willy Tarreau <w@1wt.eu> wrote:

> Hi Roberto,
> 
> On Thu, Jul 10, 2014 at 05:34:37PM -0700, Roberto Peon wrote:
>> The amount of latency induced depends mainly on size and bandwidth.
>> Assuming that the header size is 8k, and a link is 1Mb/s (as still happens
>> often for mobile devices), we're talking about 62ms of buffering before it
>> can forward, even if it has all of the headers necessary for routing within
>> the first few ms.
> 
> But here you're speaking about the serialization time on the proxy itself,
> it's irrelevant to the slow bandwidth, because I'm assuming you're not
> connecting your proxies using an 1 Mbps arcnet link :-)
> 
>> As a concrete usecase, think of any entity that needs to forward requests
>> from a slow link to a fast link.
> 
> I'm still failing to see the use case I'm afraid, because what will be
> added in this case is the time needed to serialize over the fast link.
> The problematic case would be if you insert multiple proxies over a
> slow link, which really does not make much sense.
> 
>> Additionally, in cases where there are multiple proxies as part of a load
>> balancing infrastructure, there is no need to examine the full set of
>> headers on any but one of them.. and for the response headers (of one
>> trusts the server, which can happen if one is running both proxy and
>> server), there may never be a need to examine them before forwarding.
> 
> It depends, because if you stack multiple proxies, each of them will have
> a different usage. One may be a cache, another one may be used to perform
> anti-virus processing etc... Also, we're speaking about devices where the
> added time is measured in microseconds and is not noticeable by the client
> (the request serialization time is lower than the TCP connection time to
> the next hop).
> 
> For example, here at home a request to youtube, with all the fat cookies
> tracking my activity is 669 bytes. That's 21 ms over my 256kB ADSL line.
> When it reaches your gateways, it will take an extra 5 microseconds if
> they are connected using GigE, or 500 nanoseconds if connected over 10GE.
> The round-trip time when the link is empty is 25 milliseconds in comparison,
> so that completely dominates the serialization time on all your proxies.
> 
> Regards,
> Willy
> 
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Friday, 11 July 2014 05:33:10 UTC