Re: Large Frame Proposal

On Jul 7, 2014, at 6:22 PM, Roberto Peon <grmocg@gmail.com> wrote:

> 
> 
> 
> On Mon, Jul 7, 2014 at 4:16 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> In message <CAP+FsNfLuFj9aFVVzy6khFBZHmB5FMeFm0+2GLSw_KVQQppyqg@mail.gmail.com>, Roberto Peon wri
> tes:
> 
> >Lets make it concrete.
> >Client A,is speaking to a proxy B, to servers C, D.
> >Server C wants a max header limit of 4k.
> >Server D wants a max header limit of 8k.
> >
> >What does proxy B do?
> 
> What is proxy B's job?
> 
> If proxy B is a corporate SOX-compliance proxy that needs your
> kerberos ticket to let you through, it will tell you that it
> takes 64K frames and send you 413 if the headerset is bigger
> than what C or D (depending on Host:) will accept, after having
> stripped the Kerberos ticket out.
> 
> Sure.
>  
> 
> If proxy B is a CDN with two servers behind RFC1149 connectivity,
> it will announce something big enough for what you might send
> and then it will file away at the headers, in contract with
> server C and D, until they are small enough to tied to the legs.
> 
> And if it can't, then it will 413 the request for lack of any other option.
>  
> 
> If proxy B is a load-balancer in front of C and D, it will
> advertise the max, ie 8K, and if you send an 8K header
> destined for server C, it will either send you a 413 or
> in contract with server C rewrite the request so server
> C gets to emit the 413.
> 
> Agreed.
> I'll note that we're still needing to send 413s from proxies/loadbalancers/gateways in many cases.
> 

The point is not to eliminate 413s though. The point is to mitigate HOL blocking and significantly reduce connection drops between hops. Although you also get a nice benefit of reducing the total processing cost of participants.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Tuesday, 8 July 2014 00:05:12 UTC