- From: Jason Greene <jason.greene@redhat.com>
- Date: Mon, 4 Aug 2014 16:58:57 -0500
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: "Simpson, Robby (GE Energy Management)" <robby.simpson@ge.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Aug 4, 2014, at 4:39 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > On 4 August 2014 14:01, Simpson, Robby (GE Energy Management) > <robby.simpson@ge.com> wrote: >> This seems a bit wasteful and could also result in the peer not >> understanding the issue. Let's say I have a constrained device that can >> only buffer 4K at a time. If I receive frames > 4K, there is nothing that >> can be done to inform the peer to stop sending frames that large. At the >> end of the day, it seems one must assume the ability to handle a 16K >> frame, unless I am missing something. Granted, I suppose one could use >> the TCP receive window, but we have windowing here and I'm guessing that >> there will be cases where an entire frame will need to be held before it >> can be processed. > > The simplest thing to do if you care about avoiding the waste is to > not buffer. I'll note that the default TCP CWND is larger than 4k on > most clients, so you are more or less forced to deal with more than > you can hold. > >> In the end, is there a problem with having a minimum < 16K? > > There are, though I doubt that you'd find the reasons compelling :) > Currently, implementations are not obligated to look for the frame > size limit if they don't intend to use more than 16K. Lower values > would mean that they need to support the setting. There are still some things you can do to deal with large frames: - Advise low header space (using SETTINGS_MAX_HEADER_LIST_SIZE) - Tune flow control down limiting the size of data frames - Support > 4k data frames, but process them in smaller chunks - REFUSED_STREAM and drain all frames > your internal limit, until you get a SETTINGS ACK - In the case that clients ignore the header advisory after ACK, REFUSED_STREAM or GOAWAY sending a 431 -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Monday, 4 August 2014 21:59:33 UTC