- From: Simpson, Robby (GE Energy Management) <robby.simpson@ge.com>
- Date: Mon, 4 Aug 2014 22:05:42 +0000
- To: Martin Thomson <martin.thomson@gmail.com>
- CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 8/4/14, 5: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. My key concern is not the default, but rather the minimum, when it comes to MAX_FRAME_SIZE. I can handle the compromise that the default may be large and constrained devices may need to deal and then lower it. But with a minimum of 16K, I fear that a lot of devices may simply be unable to ever participate (at least reliably). Also, as an aside, by "waste" I also worry about transmissions (battery life). >> 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. Yea, at least not strongly compelling. :) Was the number based on the average response size or something? Some of those fun heavy tail measurements? >>>Note that we can't do things like change the header table size without >>>affecting other users, like the web, more than we'd like. >> >> Understood. I'm not suggesting changing the default HEADER_TABLE_SIZE. >> And I certainly understand web is the predominant use case. > >Well header table is going to be a major source of pain for >constrained devices, hence my mention of it. I agree, but at least it can be lowered, unless I am missing something. >>>As for alignment, I realize that we're not perfect, but the only way >>>to get alignment is to pad, and no one has been willing to do that. >> >> My first suggestion is to not make the 'E' bit optional in the HEADERS >> Frame Payload. > >Whether E is present is coupled to whether the priority field is >present. We do have byte alignment, just not word alignment (whatever >that happens to be on your platform [1]). How does one have byte alignment without 'E'? [Pad Length (8)] + Stream Dependency (31) + [Weight (8)] is my read. >> Is it problematic to have the initial value for the flow control window >><= >> the minimum maximum frame size (whatever it may be)? > >This one is a real problem. This would have a major impact on our >ability to send requests prior to getting settings. Those first round >trips are crucial for performance. The stream flow control window >might be reduced without serious impact, I guess, but I'm sure that >you are most concerned about the connection window. Note also that >headers don't consume flow control credits. OK - Robby >--Martin > >[1] >https://en.wikipedia.org/wiki/Word_%28computer_architecture%29#Table_of_wo >rd_sizes
Received on Monday, 4 August 2014 22:06:09 UTC