[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/ [EMAIL PROTECTED] [EMAIL PROTECTED] [1] http://www.isi.edu/ant/address/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
