Oy. The concept is fairly simple. If you need to know the entire size of the headers before one is allowed to send any of it (as would be the case), then one must wait for all of the headers data to arrive (and mutate it) before forwarding. Thus, adding at a minimum: header-bytes/bandwidth seconds of latency per gateway (not to mention the additional memory for the buffering). I'd expect this to add a 10th of a ms per gateway or so, more on more constrained links. -=R On Mon, Jul 7, 2014 at 2:58 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > In message <CAP+FsNdq4O0awp=B=5EPFh4y5XN= > KKM2xr6DvcVkrMKpSzDn6Q@mail.gmail.com>, Roberto Peon wri > tes: > > >In the response path, gateways can have significantly more leeway than the > >proposed change (requiring buffering) would allow-- today I can know, by > >virtue of the fact that I'm running both the gateway and the server, that > >the server isn't going to do anything that can't be checked on a key-value > >basis (as opposed to a full-headers basis), and requiring buffering for > >each gateway on that path induces more latency than needs to be there, > [...] > > Can you please tell me, blow by blow, packet by packet, where that latency > comes from, because I can't find a place to fit it in ? > > Just because you get your HEADERS in a single frame doesn't mean you cannot > process it byte by byte (or MTU by MTU) if you want to ? > > The only real difference is that you get to know up front how much > will be coming your way. I have a hard time seeing how that can > hurt your latency ? > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. >
Received on Monday, 7 July 2014 22:05:11 UTC