Re: [Tzdist] Fwd: [tzdist] #32 (service): managing historical data

Cyrus Daboo <cyrus@daboo.name> Sun, 14 December 2014 16:04 UTC

Return-Path: <cyrus@daboo.name>
X-Original-To: tzdist@ietfa.amsl.com
Delivered-To: tzdist@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA261A6F33 for <tzdist@ietfa.amsl.com>; Sun, 14 Dec 2014 08:04:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.91
X-Spam-Level:
X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCzasa3HvQCV for <tzdist@ietfa.amsl.com>; Sun, 14 Dec 2014 08:04:28 -0800 (PST)
Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7F11A01D8 for <tzdist@ietf.org>; Sun, 14 Dec 2014 08:04:28 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 1DC38612C73; Sun, 14 Dec 2014 11:04:27 -0500 (EST)
X-Virus-Scanned: amavisd-new at example.com
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yzr08iCSGjB0; Sun, 14 Dec 2014 11:04:26 -0500 (EST)
Received: from [10.0.1.25] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id 53D36612C68; Sun, 14 Dec 2014 11:04:26 -0500 (EST)
Date: Sun, 14 Dec 2014 11:04:23 -0500
From: Cyrus Daboo <cyrus@daboo.name>
To: Paul Eggert <eggert@cs.ucla.edu>, Lester Caine <lester@lsces.co.uk>, tzdist@ietf.org
Message-ID: <5F5A838C3A2D2B962EB84B92@cyrus.local>
In-Reply-To: <548C8535.5060508@cs.ucla.edu>
References: <059.5da79d7c9d394e20e3c22513cfe04c33@tools.ietf.org> <676B23282D9F7F1DCE6A54C7@caldav.corp.apple.com> <CAFpi07x79gJLEBWmpxWv7V13CiwmeKGy7bwS1=+ukp-sKmwFxA@mail.gmail.com> <5488921B.8020900@lsces.co.uk> <5488973F.7050400@andrew.cmu.edu> <54889C39.1080103@lsces.co.uk> <D2BE5C3BFE11019ECF4BEF62@caldav.corp.apple.com> <5488A6E6.8050903@lsces.co.uk> <CADC+-gTiyJ4QHZT6m3je9M9-ifSELnSWgmgy7iXSWNS+p8pthg@mail.gmail.com> <5488C0EA.8090505@lsces.co.uk> <CADC+-gTgckSe1ca6Sai6RguQid=ReM7bH6K8+dVVFm-YfbpFbA@mail.gmail.com> <5488DA56.2090306@lsces.co.uk> <CADC+-gQN=Qb2y8M-bHnPzMcK8r=xUG-seQ7XzvZwwcWsHpHnBQ@mail.gmail.com> <54895986.6060806@lsces.co.uk> <5489CA90.1070307@gmail.com> <35BC5886C9A58F866E8A46A8@caldav.corp.apple.com> <5489D9F7.3080207@gmail.com> <D196D63077FEC1B090DF7C86@caldav.corp.apple.com> <5489F79E.4080909@gmail.com> <BC19CC6916DC0E59CA63737D@caldav.corp.apple.com> <548B929C.3010505@gmail.com> <548C04F8.30005@lsces.co.uk> <D0F712C2A7EF425A8887E231@cyrus.local> <548C8535.5060508@cs.ucla.edu>
X-Mailer: Mulberry/4.1.0b1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size="3853"
Archived-At: http://mailarchive.ietf.org/arch/msg/tzdist/okh9BnwTX2_omPVvt3w30XhJg8Q
Subject: Re: [Tzdist] Fwd: [tzdist] #32 (service): managing historical data
X-BeenThere: tzdist@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <tzdist.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tzdist>, <mailto:tzdist-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tzdist/>
List-Post: <mailto:tzdist@ietf.org>
List-Help: <mailto:tzdist-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tzdist>, <mailto:tzdist-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Dec 2014 16:04:31 -0000

Hi Paul,

--On December 13, 2014 at 10:28:05 AM -0800 Paul Eggert 
<eggert@cs.ucla.edu> wrote:

>> 1) Replace the "dtstamp" member of the list action response with a
>> "version" member...
>>
>> 2) The new "version" member value could then be used as the value for
>> "changedsince"...
>
> I think something like this could work, but I confess that I'm not
> following all the details.  In particular I'm not understanding the
> relationship between "version" and ETag (mentioned in (3), below).  Why
> doesn't ETag subsume "version"?  Shouldn't we have just one versioning
> mechanism, not two or three? For example, if the ETag doesn't change for
> America/Los_Angeles between tz2014a and tz2014b, why does an
> America/Los_Angeles-using client need to even worry about versions?  It
> can just say "give me the latest ETag for America/Los_Angeles", verify
> that the ETag hasn't changed, and be done.

Well ETag is something very specific to the HTTP protocol and is used in 
several ways - in particular it is important for caching by intermediaries 
etc. Plus there are reasons when you might want to refresh the client data 
in the absence of a publisher version upgrade (e.g., the tzdist server is 
using a more efficient, compact representation that it previously had). So 
tying the ETag to the publisher version is probably not the right approach. 
It is worth noting, however, that HTTP has the concept of "strong" and 
"weak" ETags (see <http://tools.ietf.org/html/rfc7232#section-2.1>). It may 
be possible to make use of "weak" ETags for the version id.

>> I would prefer it if clients did
>> not have to download an entire time zone just to find out that the only
>> difference is a change in the version. That is what would happen if the
>> client only used ETag and If-None-Match with HTTP....
>

> Are we really going to bother about shrinking 0.0063 b/s to an even
> smaller number?  We can't shrink the headers, so even with an ideal
> protocol that compresses changes to zero bytes, we could at best shrink a
> request+response pair to ((600 + 200) + (600 + 0)) = 1400 bytes, or
> 0.0035 b/s.  And the tradeoff is a more-complicated client that consumes
> more energy and development time. It's not at all clear that this tiny
> benefit is worth the cost.

So when we first developed CalDAV we were not that concerned with 
scaleability issues - or key goal was to just get any acceptable, 
interoperable calendaring and scheduling client/server protocol into use. 
Since then CalDAV's use has spread to services hosting potentially 10's to 
100's of millions of users. In that kind of environment, yes, every byte 
does count, because the sum of all those extra bytes across the full set of 
users/devices is huge. For CalDAV we have incrementally added new protocol 
features to improve scaleability (e.g., the WebDAV sync report). I don't 
want to ignore scaleability this time around, since the ultimate goal of 
tzdist is to have every device on the planet that needs to know local time, 
make use of it. It may well be that we have large service providers 
supporting it and they will care about how often and how much data clients 
will download. So I really don't want a change to a time zone version id, 
with nothing else being different, to invalidate a client cache and force a 
download.

As far as more complicated goes - simply making use of existing HTTP 
features such as ETags and conditional responses is not an issue because 
nearly every device we are likely to care about has an HTTP protocol stack 
that copes with those aspects of the protocol.

That said, at this point, it may be simply better to take the CalDAV 
approach and go with something that may be less efficient in the first 
place, but has the necessary extensibility to be scaled to huge deployments 
when the demand arises.


-- 
Cyrus Daboo