Re: Striving for Compromise (Consensus?)

On 12/07/2014 10:37 a.m., Martin Thomson wrote:
> On 11 July 2014 14:53, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>> If 256 bytes is enough for basic interop, we shouldn't require more.
> 
> I find this reasonably convincing.  Interoperability is what we are
> looking for here.
> 
> Though I'll note that the arguments regarding cost of implementation
> are very much less convincing. Those devices, when presented with a
> peer that doesn't know their capabilities, will have to deal with 16k
> frames until their setting is seen.  And I'm not sure that 16k is so
> hard for a constrained device to handle anyway.  I keep hearing about
> what amazing things that even the most constrained hardware can handle
> (TLS stacks, node.js, etc...).  So I'm disinclined to lend too much
> weight to arguments about limited capabilities.
> 
> That said, if 256 is enough to get something working, then that's a
> good argument.
> 
> An alternative approach would be to set the default and minimum to the
> same value.  That has other benefits, like being able to completely
> ignore a setting from the other side.  That seems pretty attractive.
> 

When I sueggested that same point some time back you convinced me that
is was perfectly reasonable for a constrained device to reject a number
too-big frames and streams on connection initiation. Nothing has changed
since then. So why is it now such a burden to reject some frames up
front on a constrained processor?
 If the constrained processor is going to pick 256 in the first place
its something like an 8-bit processor counting memory by the byte. Even
16-bit ATOM these days have a few hundreds of KB of RAM attached.

Amos

Received on Saturday, 12 July 2014 03:43:08 UTC