Re: bohe and delta experimentation...

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<grmocg@gmail.com>  wrote:
>
>> How about setting epoch as the first request in the connection? :)
>> -=R
>>
>>
>> On Wed, Jan 16, 2013 at 3:45 PM, Nico Williams<nico@cryptonector.com>wrote:
>>
>>> On Wed, Jan 16, 2013 at 5:39 PM, Mark Nottingham<mnot@mnot.net>  wrote:
>>>> On 17/01/2013, at 10:35 AM, Nico Williams<nico@cryptonector.com>
>>> 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.
>>>
>>>
>>
>

Received on Friday, 18 January 2013 07:06:29 UTC