Re: bohe and delta experimentation...

[Mark Nottingham <[e-mail]>]

I feel like we're starting to focus a bit too closely on dates here (not just you, Martin!).

Let's look at the bigger picture, and other headers, before getting too deep here; we're talking about saving a handful of bytes at this point, and we haven't yet looked at URLs, etc. 

Cheers,


On 18/01/2013, at 6:05 PM, Martin J. Dürst <[e-mail]> wrote:

> On 2013/01/17 8:49, Roberto Peon wrote:
>> Er, by which I mean that dates can be relative to the time stamped by
>> something and kept for the connection duration. That would reduce the
>> number of bits needed by a fair margin, assuming that is desirable.
>> -=R
> 
> I was thinking about something similar, but on a bigger scale. If we have an encoding that can cover about 80 years (this is a simplification from Unix time does, which is 1970-2037 with 31 bits), then if we assume every server around the globe understands that we are currently somewhere between 2010 and 2020, we could just use that as a very rough base point. In that case, we can't use a strict offset, because that would make dates move around every time we move to a new decade. But what we can do is to just rotate around. For this rotation to work, we have to leave some empty space. Below is a very very rough table of how something like this could work.
> 
> Assume we have three bits in a prefix to label 8 different decades. Then in each decade as indicated below on the left side, the prefixes would be used with the meaning as indicated at the top of the table.
> 
>           1970 1980 1990 2000 2010 2020 2030 2040 2050 2060 2070 2080
>            -    -    -    -    -    -    -    -    -    -    -    -
>           1980 1990 2000 2010 2020 2030 2040 2050 2060 2070 2080 2090
> 
> 1970-1980    0    1    2    3    x    x    x    x    x    x    x    x
> 1980-1990    0    1    2    3    4    x    x    x    x    x    x    x
> 1990-2000    0    1    2    3    4    5    x    x    x    x    x    x
> 2000-2010    x    1    2    3    4    5    6    x    x    x    x    x
> 2010-2020    x    x    2    3    4    5    6    7    x    x    x    x
> 2020-2030    x    x    x    3    4    5    6    7    0    x    x    x
> 2030-3040    x    x    x    x    4    5    6    7    0    1    x    x
> 2040-2050    x    x    x    x    x    5    6    7    0    1    2    x
> 2050-2060    x    x    x    x    x    x    6    7    0    1    2    3
> 
> So as an example, in our current decade, we would use prefix 2 to indicated dates between 1990 and 2000, prefix 4 to indicate dates in our decade, and prefix 7 to indicate dates between 2040 and 2050. Prefixes 0 and 1 are on purpose currently out of service to avoid any misunderstadings (does prefix 0 refer to 1970-80 or to 2050-60?). This way we avoid problems at the start/end of a decade, when some servers might think they are still in the old decade, where some others already think they are in the new decade.
> 
> This is just a very rough sketch; the decades should be non-overlapping (1991-2000), it shouldn't be exactly decades, but some other intervals that we can cover with an exact number of bits. And maybe the past/future balance isn't ideal (currently 2 past and 3 future decades, maybe just 1 future and 4 past is better, or so).
> 
> Anyway, I hope you can see the basic principles of the system: Use a rotating scheme with a very rough current anchoring and a wide-enough period of slack to avoid ambiguities.
> 
> Regards,    Martin.
> 
> 
>> On Wed, Jan 16, 2013 at 3:48 PM, Roberto Peon<[e-mail]>  wrote:
>> 
>>> How about setting epoch as the first request in the connection? :)
>>> -=R
>>> 
>>> 
>>> On Wed, Jan 16, 2013 at 3:45 PM, Nico Williams<[e-mail]>wrote:
>>> 
>>>> On Wed, Jan 16, 2013 at 5:39 PM, Mark Nottingham<[e-mail]>  wrote:
>>>>> On 17/01/2013, at 10:35 AM, Nico Williams<[e-mail]>
>>>> wrote:
>>>>> Yep, but you either need to make the epoch start at least a few years
>>>> ago (old Last-Modified times, is important for heuristic freshness), OR
>>>> keep it signed (losing a bit).
>>>>> 
>>>>> And I think you need more than 12 bits for seconds in a day...
>>>> 
>>>> Oops, for some reason I thought of seconds in an hour.  So 5 more
>>>> bits, and we're about even with seconds since epoch.  Either way
>>>> getting from 24 bytes to 4 is pretty good, and no compression scheme
>>>> will do better.
>>>> 
>>>> 
>>> 
>> 

--
Mark Nottingham   http://www.mnot.net/