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

[Paul Eggert <[e-mail]>]

Cyrus Daboo wrote:
> 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.

In that case I'm puzzled why VTIMEZONE was chosen as the format for data, as 
it's pretty fat.  For America/Los_Angeles, vzic generates a VTIMEZONE format 
containing 4004 bytes, compared to the 1058 bytes that Android uses for tz 
binary format.  If the problem is that VTIMEZONE is bloated, perhaps a better 
solution would be to recommend a more-compact data format.

That being said, I'm still puzzled as to why shrinking the byte count is so 
important that we should complicate the protocol to support it.  As a 
back-of-the-envelope calculation, suppose a VTIMEZONE zone is 4000 bytes and we 
make the same assumptions as before for everything else (32-bit native tz binary 
data is 1100 bytes, the tzdist request is 200 bytes, the protocol overhead is 
600 bytes for both request and response, and there are 10 updates per year). 
Then we see the following per-client costs over time:

0.0137 b/s VTIMEZONE full copy each request
0.0063 b/s 32-bit tz binary full copy each request
0.0035 b/s tzdist version-style no-change handshake
0.0030 b/s? ETag-style no-change handshake? (not clear what's involved here)

To give us some perspective on this, if we assume a single reasonably-cheap 
server can process 300 Mb/s sustained, then a single tzdist server could support 
21 billion tzdist clients each using the least-efficient protocol mentioned 
above.  That's pretty scalable: one cheapish server should be able to handle the 
entire planet and then some.  So why are we worrying so much about making every 
byte count?  Shouldn't it be more important to keep things simple?