Re: New Version Notification for draft-nottingham-bikeshed-length-00.txt

[Martin Thomson <[e-mail]>]

Do we want approximation or a cap on size?

An upper bound is good for some of the use cases we see.  An estimate for the other cases.

At the extreme, you might say X +/- Y with Z confidence.  With fields for each.

That sounds like overengineering, but it doesn't have to be complicated in common usage.  You could say that Y and Z are implied or have defaults to simplify the common case.  From that a recipient can build to whatever assumption they like.  Find a value of f(Z) for X + Y*f(Z) that suits you.  Just want to show a progress meter, then f(Z) = 0 is probably fine.  Want to allocate space with a low risk of overflow, then you might want something like f(Z) = 2/Z.


On Fri, Mar 20, 2020, at 03:28, Willy Tarreau wrote:
> On Thu, Mar 19, 2020 at 04:25:03PM +0000, Poul-Henning Kamp wrote:
> > --------
> > In message <[e-mail]>, Willy Tarreau writes:
> > >On Thu, Mar 19, 2020 at 03:53:32PM +0000, Poul-Henning Kamp wrote:
> > 
> > >> We could make it explictly fuzzy, by definting it as kilobytes rounded down ?
> > >
> > >I think it's an excellent idea, which even goes in the direction of
> > >reducing the on-wire bytes. And given todays connections speeds, if we
> > >use it only for progress bars it could even represent megabytes rounded
> > >to the nearest. Less than 0.5 will usually not take more than a few
> > >seconds and not deserve showing an accurate progress bar.
> > 
> > I thought about that, but I know of applications where traffic is sorted
> > in "small", "medium" and "huge", where "small" is significantly less than
> > a megabyte, so I think the units should in the kilobytes rather than
> > megabytes range.  Just to throw a number out there:  Smaller than 32k.
> 
> I'm fine with this anyway.
> 
> Willy
> 
>