Re: bohe and delta experimentation...

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Fri, 18 January 2013 07:07 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C1021F8A52 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 17 Jan 2013 23:07:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.197
X-Spam-Level:
X-Spam-Status: No, score=-8.197 tagged_above=-999 required=5 tests=[AWL=2.102, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRndLzj7I4xd for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 17 Jan 2013 23:07:25 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5505621F8A6B for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 17 Jan 2013 23:07:25 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Tw625-0001UE-GG for ietf-http-wg-dist@listhub.w3.org; Fri, 18 Jan 2013 07:06:33 +0000
Resent-Date: Fri, 18 Jan 2013 07:06:33 +0000
Resent-Message-Id: <E1Tw625-0001UE-GG@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <duerst@it.aoyama.ac.jp>) id 1Tw621-0001TU-Tj for ietf-http-wg@listhub.w3.org; Fri, 18 Jan 2013 07:06:29 +0000
Received: from scintmta02.scbb.aoyama.ac.jp ([133.2.253.34]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <duerst@it.aoyama.ac.jp>) id 1Tw620-0007Xv-9a for ietf-http-wg@w3.org; Fri, 18 Jan 2013 07:06:29 +0000
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r0I760UZ004095 for <ietf-http-wg@w3.org>; Fri, 18 Jan 2013 16:06:00 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 42b9_d83e_836deb5a_613d_11e2_b0e2_001d096c5782; Fri, 18 Jan 2013 16:06:00 +0900
Received: from [IPv6:::1] ([133.2.210.1]:47775) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S162BA55> for <ietf-http-wg@w3.org> from <duerst@it.aoyama.ac.jp>; Fri, 18 Jan 2013 16:06:01 +0900
Message-ID: <50F8F44E.9040401@it.aoyama.ac.jp>
Date: Fri, 18 Jan 2013 16:05:50 +0900
From: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Roberto Peon <grmocg@gmail.com>
CC: Nico Williams <nico@cryptonector.com>, Mark Nottingham <mnot@mnot.net>, James M Snell <jasnell@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
References: <CABP7RbeNFm3ZHdtDBUJb3idJjFj0q+fxDPzxKZBhSJqXw8zWaQ@mail.gmail.com> <2FD0BBE1-59C6-4E49-ACCE-60C1A895FB7D@mnot.net> <CABP7RbdXh1mb_P-HQucksiHc1So0ggVxH5v8y7vk13g+CcWe-Q@mail.gmail.com> <DD2EFC9F-5201-4829-9E6F-BD9CF0307BB0@mnot.net> <CAK3OfOj1O82WqO0L0rNpq2qeKJoT9E0ZQrV6Y=ULETtACpYMag@mail.gmail.com> <CAK3OfOgOGFNbve_QrTrCesqrrAQRH5qWgvebBxAhoMD7_MjhjQ@mail.gmail.com> <0A36AEB6-09B9-462F-B2E8-90B67FE69980@mnot.net> <CAK3OfOhewuVdjxu7UUp49g8B33YZNJ_N-PkASkHLP213+8gquA@mail.gmail.com> <CAP+FsNdi4=Am7pZdKySHZESp79BzRzPaR3UGQM2dsOM-yAxBOA@mail.gmail.com> <CAP+FsNf++RVVAyqweCsGG45wWQyjRrT7LEyWbv+QOd7Z2XdXwg@mail.gmail.com>
In-Reply-To: <CAP+FsNf++RVVAyqweCsGG45wWQyjRrT7LEyWbv+QOd7Z2XdXwg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: none client-ip=133.2.253.34; envelope-from=duerst@it.aoyama.ac.jp; helo=scintmta02.scbb.aoyama.ac.jp
X-W3C-Hub-Spam-Status: No, score=-5.5
X-W3C-Hub-Spam-Report: AWL=-1.306, BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1Tw620-0007Xv-9a e607d7da535a196633a179f149338d44
X-Original-To: ietf-http-wg@w3.org
Subject: Re: bohe and delta experimentation...
Archived-At: <http://www.w3.org/mid/50F8F44E.9040401@it.aoyama.ac.jp>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/15985
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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.
>>>
>>>
>>
>