Re: TC voting and amendment procedure
[started drafting this a while ago; sorry if some of this is redundant now]
On Mon, Dec 03, 2007 at 06:53:47PM +1000, Anthony Towns wrote:
> But hey, you can always do an on-paper analysis even without actual data.
> The names resolve to:
> http.us/ftp.us:
> 34.9.37.225 00100010 00001001
> 64.50.236.52 01000000 00110010
Looks like the DNS has been changing a few times of late. When I queried
it, it was:
$ nslookup http.us.debian.org
Server: 66.93.87.2
Address: 66.93.87.2#53
Non-authoritative answer:
Name: http.us.debian.org
Address: 64.50.236.52
Name: http.us.debian.org
Address: 64.50.238.52
Name: http.us.debian.org
Address: 128.30.2.36
Name: http.us.debian.org
Address: 204.152.191.39
Name: http.us.debian.org
Address: 35.9.37.225
$
So that's:
35.9.37.225 00100011 00001001
64.50.236.52 01000000 00110010
64.50.238.52 01000000 00110010
128.30.2.36 10000000 00011110
204.152.191.39 11001100 10011000
> security:
> 128.31.0.36 10000000 00011111
> 212.211.132.32 11010100 11010011
> 212.211.132.250 11010100 11010011
> Those compare with the private ranges:
> 10.0.0.0/32 00001010 ...
> 172.16.0.0/12 10101100 0001...
> 192.168.0.0/16 11000000 10101000
> The rule9/rule10 ordering means that we take the longest common prefix,
> then do round-robin.
> For http.us that would lead to:
> RR for addresses above 128.0.0.0 (including 192.168/172.16)
--> 100%/0% split for addresses above 192.0.0.0 (including 192.168)
--> 100%/0% split for addresses in 128.0.0.0/2 (including 172.16)
> 100%/0% split for 10.0.0 addresses
> 100%/0% split for addresses below 64.0.0.0
> 0%/100% split for addresses above 64.0.0.0 but below 128.0.0.0
--> 50/50 split for addresses in 64.0.0.0/2 (surprisingly, despite appearing
to be in the same address range, the reverse DNS and BGP suggest that the
hosts are located at or interface with two separate peering points, so the
split may in fact not be immaterial)
> For security it gives:
> RR for addresses below 128.0.0.0
> RR for 10.0.0.0 addresses
> 100%/0%/0% split for addresses below 192.0.0.0 but above 128.0.0.0
> 100%/0%/0% split for 172.16..
> 0%/50%/50% RR split for addresses above 192.0.0.0
> 0%/50%/50% RR split for 192.168/16
Right.
> So http.us would be biassed by 10.0.0.0 addresses, but everything else
> seems fairly balanced, and afaics 10.0.0.0 addresses alone, while, likely
> to be significant shouldn't be completely dominating.
It's also going to be biased by the fact that this is a country-specific
mirror alias, and even assuming use of public IP address space was fairly
evenly distributed as a whole (which it's not, as noted before 224.0.0.0/3
is reserved for multicast which wipes out half of the theoretically
available public address space for clients in 192.0.0.0/3), clients of
http.us are (for the most part) going to be located in the US, which means
their public addresses are going to be in blocks managed by ARIN rather than
one of the other registrars.
This principally means 204/6 and 208/7 (which are old allocations to folks
like MCI that predate current IP assignment policies and therefore probably
fairly sparsely populated - the ISI survey[1] supports this), 198/7, 216/8,
some scattered stuff throughout 128/2 (mostly educational institutions
AFAIK), 96/6 (which appears to be allocated but unused?), 64/5, 72/6, and,
well, a substantial chunk of 0.0.0.0/2 (including 24.0.0.0/8 == US cable
providers), given that most of the first-come-first-serve /8s that were
given out in the early days were given to US companies.
That still doesn't let us draw any concrete conclusions, because we don't
have solid information about the ratios of hosts with public vs. private IP
addresses among Debian users, or any idea about biases that might exist in
the distribution of Debian hosts among netblocks, or netblock-specific
preferences for NAT configurations (e.g., "all the customers in 24/8 get
shipped routers which serve 10/8 addresses over DHCP by default").
[My own expectations are that 128.30.2.36 would see reduced traffic (.edu
sites are more likely than others to give their end users public IPs, but
sites with addresses in the 128/2 range also probably represent
significantly less than 1/5 of the total number of US Debian deployments;
and very few people seem to know the 172.16/12 private addresses even exist,
so this server won't pick up many clients by way of NAT), 64.50.236.52 and
64.50.238.52 see slightly reduced traffic because they're splitting 50/50
the clients corresponding to 64/2 (which is a large userbase but with no
supplementing from NAT), and 35.9.37.225 would see significantly increased
traffic as a result of being the sole target for all 10/8 NAT configurations
and 24/8 cable customers.
The last address, 204.152.191.39, seems like it could be biased in either
direction, with 204/6 and 208/7 representing a relatively small chunk of the
public address space but 192.168.0.0/16 representing a substantial number of
NAT machines.]
> Which leaves as conclusions:
> - there's no available evidence of a problem from Debian server logs
Er, because the person looking into it didn't yet have access to Debian
server logs, so that's not very conclusive.
> - ftp.us, http.us and security.d.o all seem to still be functioning
> from a user's perspective
Which I think is really just a way of saying "any problems affecting users
haven't been so severe that the users have escalated it to our attention".
But I see little reason to expect that users /would/ escalate it to our
attention; if users find it worth trying to complain about the problem at
all rather than silently accepting service degradation, I don't think a TC
bug about DNS resolution is going to be their first stop.
> - the understanding of the issue we've got so far implies that this
> would only cause fairly minor load balancing problems for the current
> Debian hosts
Given the current and potential spread on http.us.d.o, I think there's
insufficient information to conclude the load balancing problems would be
minor.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
[1] http://www.isi.edu/ant/address/
Reply to: