Subject: [Tzdist] Ticket #3: scalability and expected volume of data

From: Daniel Migault <[email-masked]>
Date: Sun, 31 Aug 2014 16:46:08 +0200

Hi,

There are a few questions related to scalability of the service.
http://trac.tools.ietf.org/wg/tzdist/trac/ticket/3 and
http://trac.tools.ietf.org/wg/tzdist/trac/ticket/8

I understand that the time zones are distributed, and in that sense
provides a scalable architecture. However, I am wondering what volume of
data is expected to be transfer for each end user, or how many servers are
expected worldwide if all client makes a request everyday.

These consideration may not directly related to the protocol, however, they
impact the underlying protocols like TLS and may define if we have to use
POSH or not.

BR,
Daniel

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Tobias Conradi <[email-masked]>
Date: Sun, 31 Aug 2014 17:28:16 +0200

On Sun, Aug 31, 2014 at 4:46 PM, Daniel Migault <[email-masked]> wrote:

> I am wondering what volume of data is
> expected to be transfer for each end user

To analyze this I would split transfers into different cases:

1) first time setup
2) updating data set for one tzid
2.1) for tzids where the data often changes
2.2) for tzids where it rarely changes
2.3) for tzids where almost never changes (e.g. no DST used ever)
3) updating all data sets

World population ~ 7 billion:
~ 1 billion in China use UTC+08:00, no DST
~ 1 billion in India use UTC+05:30, no DST

Simple clocks that rely on tzdist would only need to check data for
one zone and only would need to check whether the current and future
offsets changed.

Data transfer is affected by the "substantive"-concept, which I
proposed to be replaced:

http://www.ietf.org/mail-archive/web/tzdist/current/msg00237.html

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Lester Caine <[email-masked]>
Date: Sun, 31 Aug 2014 22:04:13 +0100

> http://www.ietf.org/mail-archive/web/tzdist/current/msg00237.html

Simple clocks only need to use the 'expand' version of a timezone, and
for a large number of timezones that is a single value ... It is only a
few areas of the world where we have a potential uncertainty that the
future transitions may not be accurate and we only need to be able to
handle potential changes of a single time at short notice.

A more complete set of material relating to a timezone depends on the
type of server being accessed, and the restricted view provided by a
1970's truncated set does not need much more data than provided by the
simple expanded view? Documentation is only required for the potential
problem above.

What is not currently even available is a comprehensive untruncated data
set for which updates may well contain a lot more data. BUT when we can
actually discuss providing that source I would hope we are also at a
stage where only the changes need to be replicated? We do not as yet
even have agreement to include that data in tz, and without it tzdist
has nothing to work with anyway.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk