Using non-ISP DNS resolvers bad??

Huh????

There's a bunch of rumor out on the Net suggesting that users of 
AppleTV, who use other than their ISP's native DNS resolvers, 
are seeing download performance troubles because the CDNs being 
used are somehow keyed to the user's choice of DNS.  Huh???

That makes no sense to me, and I can't really even see how that 
might actually be possible and/or work.  Has there been any 
discussion of this issue here?

-- 
________________________________________________________________
Steve.   / Scarce as facts are, supply too often exceeds demand.
0
Steve
12/30/2010 9:43:41 PM
grc.news.feedback 4181 articles. 0 followers. Follow

51 Replies
4599 Views

Similar Articles

[PageSpeed] 43

On 12/30/2010 3:43 PM, Steve Gibson wrote:
> Huh????
>
> There's a bunch of rumor out on the Net suggesting that users of
> AppleTV, who use other than their ISP's native DNS resolvers,
> are seeing download performance troubles because the CDNs being
> used are somehow keyed to the user's choice of DNS.  Huh???
>
> That makes no sense to me, and I can't really even see how that
> might actually be possible and/or work.  Has there been any
> discussion of this issue here?
>
 From this blog:
http://joemaller.com/2577/itunes-slowdowns-with-google-dns/

"This totally makes sense. iTunes� video content is delivered by Akamai 
who has distributed massive datastores around the world so those large 
files originate from nearby servers and spend less time getting switched 
around the network. Akamai somehow uses our DNS routing to determine our 
location. If Google DNS or OpenDNS routes everyone to Akamai the same 
way, then those Akamai nodes and the pipes leading to them get overwhelmed."

-- 
Sired, Squired, Hired, RETIRED.
0
Retired
12/30/2010 9:54:52 PM
On 12/30/2010 3:54 PM, Retired wrote:
<snip>
More here:
http://www.appleinsider.com/articles/10/12/20/apple_tv_itunes_downloads_slowed_by_google_dns.html
-- 
Sired, Squired, Hired, RETIRED.
0
Retired
12/31/2010 12:08:12 AM
On Thu, 30 Dec 2010 13:43:41 -0800, Steve Gibson wrote:

>That makes no sense to me, and I can't really even see how that 
>might actually be possible and/or work.  Has there been any 
>discussion of this issue here?

Something smells fishy.  Retired's blog quote mentions Akamai but I
thought they used Anycast or similar.

Could Akamai authoritative servers seed different DNS systems with
different IPs?  It would have to be something like that - at access
time they couldn't otherwise know what DNS server was used.

Naw... too far fetched.

Bill
-- 
Bill_MI - Bill in Michigan
Expert Opinions $20, Shut-Up $50
0
Bill_MI
12/31/2010 1:12:25 AM
On Thu, 30 Dec 2010 20:12:25 -0500, Bill_MI wrote:

>Could Akamai authoritative servers seed different DNS systems with
>different IPs?  It would have to be something like that - at access
>time they couldn't otherwise know what DNS server was used.

I wonder... if we stumbled into some form of system Akamai uses to
distinguish between customer systems.  Like... Apple DNS gets special
IPS through DNS so they get counted and can deliver offers, etc... or
detect hackers attempting to get Apple content from a non-Apple
network.

Someone shoot it down... sounds plausible.  What didn't I think of?

Bill
-- 
Bill_MI - Bill in Michigan
Expert Opinions $20, Shut-Up $50
0
Bill_MI
12/31/2010 1:20:17 AM
[for the unabridged version, see Bill_MI's post above]

> On Thu, 30 Dec 2010 20:12:25 -0500, Bill_MI wrote:
> 
> >Could Akamai authoritative servers seed different DNS systems with
> >different IPs?  It would have to be something like that - at access
> >time they couldn't otherwise know what DNS server was used.
> 
> I wonder... if we stumbled into some form of system Akamai uses to
> distinguish between customer systems.  Like... Apple DNS gets special
> IPS through DNS so they get counted and can deliver offers, etc... or
> detect hackers attempting to get Apple content from a non-Apple
> network.
> 
> Someone shoot it down... sounds plausible.  What didn't I think of?

I agree Bill.  The idea of different DNS resolvers receiving and 
distributing different IPs was the *ONLY* way I could see for 
this odd phenomenon to occur.  I didn't want to seed the dialog 
with that, for fear of squelching any other ideas that someone 
might have.  But your corroboration of this as the only thing 
that comes to mind fits my thinking too.

-- 
________________________________________________________________
Steve.   / Scarce as facts are, supply too often exceeds demand.
0
Steve
12/31/2010 1:24:26 AM
[for the unabridged version, see Retired's post above]

>  From this blog:
> http://joemaller.com/2577/itunes-slowdowns-with-google-dns/
> 
> "This totally makes sense. iTunes� video content is delivered by Akamai 
> who has distributed massive datastores around the world so those large 
> files originate from nearby servers and spend less time getting switched 
> around the network. Akamai somehow uses our DNS routing to determine our 
> location. If Google DNS or OpenDNS routes everyone to Akamai the same 
> way, then those Akamai nodes and the pipes leading to them get overwhelmed."

Well, it might make "total sense" to that writer, but it doesn't 
to those of us who have spent a great deal of time working our 
way around the Internet's packets.

I've seen all of that stuff on the Net and I've been waiting, 
hoping, for someone authoritative to provide an explanation that 
actually *does* make sense!  <g>

Thanks for providing the links that I didn't in my initial 
posting!

-- 
________________________________________________________________
Steve.   / Scarce as facts are, supply too often exceeds demand.
0
Steve
12/31/2010 1:27:06 AM
On Thu, 30 Dec 2010 17:24:26 -0800, Steve Gibson wrote:

>I agree Bill.  The idea of different DNS resolvers receiving and 
>distributing different IPs was the *ONLY* way I could see for 
>this odd phenomenon to occur.  I didn't want to seed the dialog 
>with that, for fear of squelching any other ideas that someone 
>might have.  But your corroboration of this as the only thing 
>that comes to mind fits my thinking too.

I was thinking further... AT&T probably ultimately controls public IPs
Apple users get.  Such IP lists are a burden to get right all the time
(for detecting Apple customers).

But if Apple users are assigned dedicated DNS servers, the fun begins.
They are more controllable.  They get special IPs - problem solved.

It still may all be speculation.  I find MANY people posting nonsense
how DNS affects things.

Bill
-- 
Bill_MI - Bill in Michigan
Expert Opinions $20, Shut-Up $50
0
Bill_MI
12/31/2010 1:32:49 AM
On Thu, 30 Dec 2010 20:32:49 -0500, Bill_MI wrote:

>It still may all be speculation.  I find MANY people posting nonsense
>how DNS affects things.

Hehe... another possibility... AT&T and Google are such good friends
(LOL... that's tongue in cheek)...

Seed Google's DNS with IPs that specify LOW/sucky priority to certain
content. :-)

Too bad Net Neutrality is dead for awhile (sigh).

Bill
-- 
Bill_MI - Bill in Michigan
Expert Opinions $20, Shut-Up $50
0
Bill_MI
12/31/2010 1:40:05 AM
On 30/12/2010 13:43, Steve Gibson wrote:
> Huh????
>
> There's a bunch of rumor out on the Net suggesting that users of
> AppleTV, who use other than their ISP's native DNS resolvers,
> are seeing download performance troubles because the CDNs being
> used are somehow keyed to the user's choice of DNS.  Huh???

Given the way CDN's put data into many ISP networks (dedicated links), it is 
conceivable that only said ISP's DNS server would have the correct IP addresses 
for the "local" CDN nodes. Of course, if the CDN network is well-designed, it 
should be possible for nodes themselves to redirect clients from the wrong side 
of the internet to canonical hostnames for their local nodes.

IIRC, there were some diagrams talking about some of this CDN stuff in order to 
help explain the L3/Comcast kerfuffle the other week, though of course they 
didn't mention DNS.

ISTM that if CDNs rely on anything more than special BGP routes, DNS could 
certainly be a factor.

> That makes no sense to me, and I can't really even see how that
> might actually be possible and/or work.  Has there been any
> discussion of this issue here?

I haven't seen any mention of it here, no, but if CDNs use location-dependent 
DNS instead of location-dependent BGP routes, such a thing is conceivable.

Regards,
Sam
0
Sam
12/31/2010 2:20:18 AM
On 30/12/2010 17:24, Steve Gibson wrote:
> [for the unabridged version, see Bill_MI's post above]
>
>> On Thu, 30 Dec 2010 20:12:25 -0500, Bill_MI wrote:
>>
>>> Could Akamai authoritative servers seed different DNS systems with
>>> different IPs?  It would have to be something like that - at access
>>> time they couldn't otherwise know what DNS server was used.
>>
>> I wonder... if we stumbled into some form of system Akamai uses to
>> distinguish between customer systems.  Like... Apple DNS gets special
>> IPS through DNS so they get counted and can deliver offers, etc... or
>> detect hackers attempting to get Apple content from a non-Apple
>> network.
>>
>> Someone shoot it down... sounds plausible.  What didn't I think of?
>
> I agree Bill.  The idea of different DNS resolvers receiving and
> distributing different IPs was the *ONLY* way I could see for
> this odd phenomenon to occur.  I didn't want to seed the dialog
> with that, for fear of squelching any other ideas that someone
> might have.  But your corroboration of this as the only thing
> that comes to mind fits my thinking too.

CDN's lease dedicated lines to most major ISPs, and generally have their servers 
in ISP datacenters. These lines (or rather, the hosts on them) might conceivably 
have special IP space allocated from the ISP's allocation pool or something, 
with only that ISP's DNS servers handing out those IP addresses for the 
appropriate hostnames.

There isn't any reason that CDN's couldn't also have canonical names for these 
ISP-specific nodes, and/or have some kind of back-end communication between 
nodes to push customers to the nearest node via redirection.

Regards,
Sam
0
Sam
12/31/2010 2:24:31 AM
On Thu, 30 Dec 2010 13:43:41 -0800, Steve Gibson wrote:

> Huh????
> 
> There's a bunch of rumor out on the Net suggesting that users of 
> AppleTV, who use other than their ISP's native DNS resolvers, 
> are seeing download performance troubles because the CDNs being 
> used are somehow keyed to the user's choice of DNS.  Huh???
> 
> That makes no sense to me, and I can't really even see how that 
> might actually be possible and/or work.  Has there been any 
> discussion of this issue here?

Not here but over there:

http://www.dslreports.com/forum/comcast

The issue is explained thus:

CDN logs the network of the DNS request, and determines what it thinks is 
best routing to the source of the request based on the network of the DNS 
server making the request. Hence, a Comcast user using OpenDNS, will 
potentially have the content delivered over less than optimal routing for 
the Comcast network.

Here is one Comcast representative's comment:

http://www.dslreports.com/forum/r24257333-

I don't really know this stuff well enough to refute those making the claim.

-- 
Norman
~Oh Lord, why have you come
~To Konnyu, with the Lion and the Drum
0
Norman
12/31/2010 5:12:16 AM
On Thu, 30 Dec 2010 20:32:49 -0500, Bill_MI wrote:

> I was thinking further... AT&T probably ultimately controls public IPs
> Apple users get.  Such IP lists are a burden to get right all the time
> (for detecting Apple customers).

How would AT&T control what public IP address an Apple user gets from 
Comcast?

> But if Apple users are assigned dedicated DNS servers, the fun begins.
> They are more controllable.  They get special IPs - problem solved.
> 
> It still may all be speculation.  I find MANY people posting nonsense
> how DNS affects things.

The way it was explained, assuming I understood the explanation, a Comcast 
user (this explanation is Comcast-centric because it was made in a Comcast 
forum) makes a request for content from a CDN, the CDN is aware of the 
network originating the DNS request. It then determines optimal routing 
between the CDN transit network and the DNS network; which may be less than 
optimal if the destination for the content is not on the DNS server transit 
network. Now, if that actually makes sense to anyone who knows what is going 
on, they probably have an advantage over what I know.

Here is one Comcast representative's explanation:

http://www.dslreports.com/forum/r24257333-

Maybe I didn't quite understand how this all works, though.  ;)

-- 
Norman
~Oh Lord, why have you come
~To Konnyu, with the Lion and the Drum
0
Norman
12/31/2010 5:13:10 AM
On Thu, 30 Dec 2010 21:13:10 -0800, Norman Miller wrote:

>How would AT&T control what public IP address an Apple user gets from 
>Comcast?

I was using the link from "Retired" which was Ipod slow when using
Google DNS as my example.

>Here is one Comcast representative's explanation:
>
>http://www.dslreports.com/forum/r24257333-

Jason said it: "Often a 3rd party DNS will give you an answer to a
different content location that may not route over direct
interconnects but over other networks to get to the destination
content."

And there's one, and only one, way that DNS can "give you an answer to
a different content location" - they get a DIFFERENT IP!  It's tied to
routing the only way DNS can be - by supplying different IPs from one
DNS than another DNS.

At least that's as I know it.  Anyone differs, please do jump in.

I suspect Akamai, in a dispute with Comcast as we speak, doesn't want
such details to be common knowledge. ;-)

Bill
-- 
Bill_MI - Bill in Michigan
Expert Opinions $20, Shut-Up $50
0
Bill_MI
12/31/2010 6:15:02 AM
On Fri, 31 Dec 2010 01:15:02 -0500, Bill_MI wrote:

>I was using the link from "Retired" which was Ipod slow when using
>Google DNS as my example.

I'm probably getting Ipod and Ipad mixed up... I've never held an
Ianything but hear Ipads are on the infamous AT&T network. :-)

So Comcast DNS should be delivering IPs of Akamai servers positioned
strategically for the Comcast network.  Google DNS gives other IPs,
not optimized for Comcast.  That's how it must work in a nutshell.

Bill
-- 
Bill_MI - Bill in Michigan
Expert Opinions $20, Shut-Up $50
0
Bill_MI
12/31/2010 6:28:07 AM
Norman Miller <exfenestrate@spammers.invalid> wrote in
news:1pv5egaunom3c$.dlg@kozue.opteron.invalid: 

> CDN logs the network of the DNS request, and determines what it thinks
> is best routing to the source of the request based on the network of
> the DNS server making the request. Hence, a Comcast user using
> OpenDNS, will potentially have the content delivered over less than
> optimal routing for the Comcast network.

http://list.waikato.ac.nz/pipermail/nznog/2010-August/016883.html

Be a bit of a detective and you can recreate the whole thread that had tons 
of really interesting information about how Akamai works from a senior 
engineer there.

I did put up a post quite a while ago about testing the GRC DNS tool and 
changing the DNS on my IPCop broke things.  I switched back to my ISP DNS 
and stuff just works.  actually, even using OpenDNS causes the similar 
issues, and I don't need their filters. (Great feature though)
  I personally feel that DNS bench for the end user has little value in the 
real worls and has a negative impact on most people's internet experience 
due to how large CDNs work in the year 2010.  Saving a few ms on a lookup 
to have the content not work is a bad thing.  IMHO.

-- 
Ciao, Dave
0
Dave
12/31/2010 7:18:32 AM
On 30/12/2010 22:15, Bill_MI wrote:
[...]
> And there's one, and only one, way that DNS can "give you an answer to
> a different content location" - they get a DIFFERENT IP!  It's tied to
> routing the only way DNS can be - by supplying different IPs from one
> DNS than another DNS.

It would be possible for Akamai to embed a GUID into a URL, keying that GUID to 
a cookie in a HTTP session, and then watch to see which DNS server looks up that 
GUID to fetch the resource. The "reply" can then be spoofed to come from the CDN 
node nearest to the DNS server, or a redirect could be issued. Though why 
geo-location of a DNS-server IP would be more accurate than geo-location of a 
client IP is a puzzle to me. Maybe it is just less overhead to track the 
locations of major ISP resolvers than all of an ISP's netblocks?

Though I think the idea that major ISPs that have agreements with CDNs allowing 
them to peer directly to the ISPs datacentres might be doing something unusual 
with DNS isn't too far-fetched.

AFAIK, there are some global load-balancing schemes that at least try to rely on 
geographical DNS, too. I found reference to this document discussing a 
'wikimedia' cache network, for instance:

http://www.nedworks.org/~mark/presentations/hd2006/

But of course, any inefficiencies due to using a system like that very much 
presumes that a) the 3rd party DNS you are using isn't multi-homed with 
appropriate BGP routes (and a geographically locatable 'local' node with an IP 
address that performs resolutions) or b) the 3rd party DNS you are using is 
geographically remote.

Given that anyone who is using 3rd party DNS is quite likely, at this point, to 
have spent at least *some* time benchmarking their DNS, I think it fairly 
unlikely that people will be willing to add tens of milliseconds to every 
routine name resolution by choosing a resolver outside of their metropolitan 
area. Pushing last-mile DNS requests out onto inter-city backbones is guaranteed 
to increase latency.

Regards,
Sam
0
Sam
12/31/2010 8:50:15 AM
On 31/12/2010 0:49, Sabahattin Gucukoglu wrote:
> Even so, I have quit OpenDNS, never to return to my ISP's ad-laden, up-and-down
> name servers. In practice, running one's own recursive DNS server is the best
> thing one can do for oneself and one's family and friends.

Though it is utterly unscalable, and not at all how DNS is structured to operate.

Certainly, having the option to resolve addresses locally will improve 
connectivity in any number of edge cases, but overall, if everyone did it, the 
DNS system would be much less efficient. I won't say it would collapse, because 
parts of it are indeed very heavily engineered, but the entire caching part of 
the system does improve performance for folks who don't happen to be the first 
person to query a domain after the TTL at the ISP's cache expires. This also 
means a large customer-base puts a diminishing load on the DNS system. The 
larger the ISP (provided they do their DNS right, that is) the more efficient.

No doubt even the proliferation of tools like DNSB and the benchmark hosted by 
google shows up as a slight bump in CPU time on some system somewhere.

Regards,
Sam
0
Sam
12/31/2010 8:57:53 AM
Steve Gibson wrote:

>The idea of different DNS resolvers receiving and 
>distributing different IPs was the *ONLY* way I could see for 
>this odd phenomenon to occur.

As I understand it, yes this is exactly what happens.  The IP's that
Akamaied servers give is determined by where you're connecting from.  (I've
spent a LOT of time tracking the various IP blocks that are owned by Akamai
all over the net.  It's impressive and not in a good way.)

Take a look at this example.  Put 204.119.131.0 into your favorite WHOIS
client.  You'll see the main block is owned by Sprint and it's been SWIPped
to Akamai.  If you're on Sprint, this would be a likely place you'd be
directed to.  Now check 69.8.201.64   That's the same thing, but in Qwest
owned space.

Now if we really want to have some fun, we could all post what we get when
we look up aolradio.podcast.aol.com which is the Akamaized server that
serves up the high bandwidth version of Security Now (among other things).
I get 205.241.224.74 and 205.241.224.153 which are owned by Sprint and
leased to Akamai.  That's not surprising since I'm on the Sprint network
right now.

0
CA
12/31/2010 10:21:03 AM
On 31/12/2010 8:13 AM, Steve Gibson wrote:
> Huh????
>
> There's a bunch of rumor out on the Net suggesting that users of
> AppleTV, who use other than their ISP's native DNS resolvers,
> are seeing download performance troubles because the CDNs being
> used are somehow keyed to the user's choice of DNS.  Huh???
>

This problem with using remote DNS servers has been known about for 
years. Two years ago (29 Dec 2008) I warned of it, in a message to 
grc.securitynow as part of a discussion on OpenDNS. I find the message 
searching facility at 12078.net impenetrable, but I can say that the 
subject of my message was "Re: Why not OpenDNS" and it's somewhere about 
message 12700.

The text of what I wrote at the time follows:

-------------------------------------------------
      In addition to the privacy issues already discussed, there may be 
a hidden performance cost for users outside North America. My ISP
(which is highly regarded in Australia and is run by technical people, 
not bean-counters) advises against the use of OpenDNS. Their top geek, 
who happens to be their Managing Director, posted this to a user forum:

"In this day and age, the DNS (with a lot of content distribution 
networks) is done in a 'geographically sensitive' manner � returning the 
IP address of one or more servers that are geographically local to the 
requestor. Akamai, for instance, works this way.

So if you use a DNS server unrelated to your ISP, you defeat that system 
entirely and wind up with all of your content distribution network data 
retrieval happening from a server that is geographically local to your 
remote DNS provider. That can reduce performance for streaming content 
(again, like that distributed by CDN's like, and not limited to, Akamai).

Long story short � use non-local DNS servers at your own risk."

That may not matter much to U.S. users, but to people on other 
continents, it's preferable to avoid those long hops across oceans.

More extended discussions at
http://forums.whirlpool.net.au/forum-replies-archive.cfm/1100541.html
and
http://forums.whirlpool.net.au/forum-replies-archive.cfm/1090029.html

Rollo (in South Australia)
0
Rollo
12/31/2010 10:57:06 AM
On Fri, 31 Dec 2010 00:50:15 -0800, Sam Schinke wrote:

>It would be possible for Akamai to embed a GUID into a URL, keying that GUID to 
>a cookie in a HTTP session, and then watch to see which DNS server looks up that 
>GUID to fetch the resource. The "reply" can then be spoofed to come from the CDN 
>node nearest to the DNS server, or a redirect could be issued. Though why 
>geo-location of a DNS-server IP would be more accurate than geo-location of a 
>client IP is a puzzle to me. Maybe it is just less overhead to track the 
>locations of major ISP resolvers than all of an ISP's netblocks?

I imagine a fairly simple system, in the context of bulk data to large
groups on a network, and not so much individual accesses.  But both
can certainly be happening.

Take Comcast, with a network spread across the USA, as an example.
Say they have an agreement with Akamai serving up Ipod content.
Rather than individual GUIDs it's as simple as Akamai's DNS responding
to East, Central and West Comcast resolvers for Akamai-controlled
addresses.  East servers get this IP, Central a second and West a
third for the same Ipod domain name.  DNS caches so it's automatic.

So 95%, the huge bulk, of Ipod content gets to Comcast customers more
locally - right from servers close by.  Comcast is happy and Akamai is
happy.

This can be done using Anycast, too, which I always thought of as the
obvious way to do this.  Direct routing distances certainly help the
cause.  The surprise is how DNS gets involved - the whole start of
this discussion. :-)

So along comes large groups using Google or OpenDNS which doles out
addresses elsewhere - and the customer sees the slowdown if they are
on the Comcast network trying to get data from the wrong coast...
whatever.

In a related note, we learned some "gotchas" how Akamai distributes
the Security Now webcast.  When it needs to change (ooops, wrong file,
etc.) Leo described how it's easier to add a new filename
(SN-026-2.mp3 was born that way).  It seems impossible to feed Akamai
servers with a new cached copy in any reasonable timeframe, if at all!
A glimpse at the cost of playing such games with bulk content.

I should look at this - YouTube has been slow here.  But I killed my
Comcast forwarders from my local BIND after their DNS crash a few
weeks ago.  I could be seeing the affect here, too.

This is the real $$$ of why Net Neutrality gets dicey, too.
Exclusivity is tightly ingrained in the system as we speak.  When does
bulk data volume optimization start becoming censorship?  A murky line
but very real (sigh).

Sorry I'm drifting around.  Happy New Year. :-)

Bill
-- 
Bill_MI - Bill in Michigan
Expert Opinions $20, Shut-Up $50
0
Bill_MI
12/31/2010 2:36:31 PM
"CA was in NJ" <reply@the.newsgroup> wrote in message 
news:ifkapg$1n1s$1@news.grc.com...
> Steve Gibson wrote:
>
> Now if we really want to have some fun, we could all post what we get when
> we look up aolradio.podcast.aol.com which is the Akamaized server that
> serves up the high bandwidth version of Security Now (among other things).
> I get 205.241.224.74 and 205.241.224.153 which are owned by Sprint and
> leased to Akamai.  That's not surprising since I'm on the Sprint network
> right now.
>


Ok. On Verizon in Southern New Jersey I get:

>nslookup aolradio.podcast.aol.com
Server:  world4.bellatlantic.net
Address:  151.197.0.37

Non-authoritative answer:
Name:    a1043.g.akamai.net
Addresses:  63.84.95.75, 63.84.95.40
Aliases:  aolradio.podcast.aol.com
          aolradio.podcast.aol.com.edgesuite.net

BobT


0
BobT
12/31/2010 5:46:03 PM
On 31/12/2010 10:21, CA was in NJ wrote:
>
> Now if we really want to have some fun, we could all post what we get when
> we look up aolradio.podcast.aol.com

here in the UK on Virgin Media

nslookup aolradio.podcast.aol.com
Server:  cache1.service.virginmedia.net
Address:  194.168.4.100

Non-authoritative answer:
Name:    a1043.g.akamai.net
Addresses:  84.53.178.9
           84.53.178.74
Aliases:  aolradio.podcast.aol.com
           aolradio.podcast.aol.com.edgesuite.net
0
sparky
12/31/2010 6:59:44 PM
On 31/12/10 18:59, sparky wrote:
> On 31/12/2010 10:21, CA was in NJ wrote:
>>
>> Now if we really want to have some fun, we could all post what we
>> get when
>> we look up aolradio.podcast.aol.com
> 
> here in the UK on Virgin Media
> 
> nslookup aolradio.podcast.aol.com
> Server:  cache1.service.virginmedia.net
> Address:  194.168.4.100
> 
> Non-authoritative answer:
> Name:    a1043.g.akamai.net
> Addresses:  84.53.178.9
>           84.53.178.74
> Aliases:  aolradio.podcast.aol.com
>           aolradio.podcast.aol.com.edgesuite.net

Here, also in the UK, I get

Source	TTL	Address Type	Record Type1	Resolution
aolradio.podcast.aol.com.	574	IN	CNAME
aolradio.podcast.aol.com.edgesuite.net.

aolradio.podcast.aol.com.edgesuite.net.	21274	IN	CNAME	a1043.g.akamai.net.

a1043.g.akamai.net.	20	IN	A	84.53.134.136
a1043.g.akamai.net.	20	IN	A	84.53.134.138
g.akamai.net.	1477	IN	NS	n6g.akamai.net.
g.akamai.net.	1477	IN	NS	a0g.akamai.net.
g.akamai.net.	1477	IN	NS	n0g.akamai.net.
g.akamai.net.	1477	IN	NS	n1g.akamai.net.
g.akamai.net.	1477	IN	NS	n2g.akamai.net.
g.akamai.net.	1477	IN	NS	n3g.akamai.net.
g.akamai.net.	1477	IN	NS	n4g.akamai.net.
g.akamai.net.	1477	IN	NS	n5g.akamai.net.


-- 
Dave_K

0
dave_k
12/31/2010 7:24:24 PM
sparky wrote:
> here in the UK on Virgin Media
>
> nslookup aolradio.podcast.aol.com
> Server:  cache1.service.virginmedia.net
> Address:  194.168.4.100
>
> Non-authoritative answer:
> Name:    a1043.g.akamai.net
> Addresses:  84.53.178.9
>           84.53.178.74
> Aliases:  aolradio.podcast.aol.com
>           aolradio.podcast.aol.com.edgesuite.net

Interesting .........

I'm also on Virginmedia in the UK but using Treewalk on my Lan and I get :-

Non-authoritative answer:
Name:    a1043.g.akamai.net
Addresses:  195.245.127.104, 195.245.127.113
Aliases:  aolradio.podcast.aol.com
          aolradio.podcast.aol.com.edgesuite.net

Whereas if I switch to Virginmedia's DNS I get the same answer as you. (as 
expected)

Tracerts to both alternatives indicate the final target is very close to the 
Virginmedia network :-
Just last 4 hops shown :-

tracert 84.53.178.74
Tracing route to 84.53.178.74 over a maximum of 30 hops

  6    15 ms    11 ms    11 ms  nrth-tmr-2-ae6-0.network.virginmedia.net 
[213.10
5.159.34]
  7    15 ms    13 ms    21 ms  tele-ic-1-as0-0.network.virginmedia.net 
[62.253.
184.2]
  8    26 ms    33 ms    21 ms  84.53.177.193
  9    15 ms    13 ms    32 ms  84.53.178.74


tracert 195.245.127.104
Tracing route to 195.245.127.104 over a maximum of 30 hops

  6    13 ms    15 ms    14 ms  popl-tmr-2-ae5-0.network.virginmedia.net 
[213.10
5.159.6]
  7    25 ms    13 ms    13 ms  tele-ic-2-as0-0.network.virginmedia.net 
[62.253.
184.6]
  8    12 ms    16 ms    12 ms  30-14-250-212.static.virginmedia.com 
[212.250.14
..30]
  9    32 ms    14 ms    13 ms  195.245.127.104

-- 
Brian Kelly
http://kellybk.com 


0
Brian
12/31/2010 7:47:10 PM
In grc.news, message <MPG.27869cda51ce792f288b@4.79.142.203>, Steve
Gibson <news07_@_grc.com> wrote:


>There's a bunch of rumor out on the Net suggesting that users of 
>AppleTV, who use other than their ISP's native DNS resolvers, 
>are seeing download performance troubles because the CDNs being 
>used are somehow keyed to the user's choice of DNS.  

Here's an article that says, "Akamai somehow uses our DNS routing to
determine our location".

http://joemaller.com/2577/itunes-slowdowns-with-google-dns/
0
k
12/31/2010 8:17:12 PM
"sparky" <paulbyford@DONTSPAMhotmail.com> wrote in message 
news:ifl963$2s8a$1@news.grc.com...
> On 31/12/2010 10:21, CA was in NJ wrote:
>>
>> Now if we really want to have some fun, we could all post what we get 
>> when
>> we look up aolradio.podcast.aol.com
>
> here in the UK on Virgin Media
>
> nslookup aolradio.podcast.aol.com
> Server:  cache1.service.virginmedia.net
> Address:  194.168.4.100
>
> Non-authoritative answer:
> Name:    a1043.g.akamai.net
> Addresses:  84.53.178.9
>           84.53.178.74
> Aliases:  aolradio.podcast.aol.com
>           aolradio.podcast.aol.com.edgesuite.net

You could of course place your favourite CDN aliases (fastest first) in your 
host file, which is what it is still there for.
This would leave you free to choose a good non ISP based DNS server if 
needed.  -:) 


0
Regulatory
12/31/2010 8:22:42 PM
On Fri, 31 Dec 2010 18:59:44 +0000, sparky wrote:

> On 31/12/2010 10:21, CA was in NJ wrote:
>>
>> Now if we really want to have some fun, we could all post what we get when
>> we look up aolradio.podcast.aol.com
> 
> here in the UK on Virgin Media
> 
> nslookup aolradio.podcast.aol.com
> Server:  cache1.service.virginmedia.net
> Address:  194.168.4.100
> 
> Non-authoritative answer:
> Name:    a1043.g.akamai.net
> Addresses:  84.53.178.9
>            84.53.178.74
> Aliases:  aolradio.podcast.aol.com
>            aolradio.podcast.aol.com.edgesuite.net

Also in UK, and on Virgin Media

Official name: a1043.g.akamai.net
IP address: 195.245.127.104
         195.245.127.113
Aliases: aolradio.podcast.aol.com
         aolradio.podcast.aol.com.edgesuite.net

-- 
(no nym)
0
no
12/31/2010 8:40:36 PM
On Fri, 31 Dec 2010 03:21:03 -0700, CA was in NJ wrote:

>Now if we really want to have some fun, we could all post what we get when
>we look up aolradio.podcast.aol.com which is the Akamaized server that
>serves up the high bandwidth version of Security Now (among other things).
>I get 205.241.224.74 and 205.241.224.153 which are owned by Sprint and
>leased to Akamai.  That's not surprising since I'm on the Sprint network
>right now.

Yep, just tried all 12 Comcast servers across the continental US and
EVERY ONE resolves a DIFFERENT IP pair for aolradio.podcast.aol.com.
I thought it might be by region - Nope!

Then they use DNSSEC Anycast servers 75.75.75.75 and 75.75.76.76 for
primary and secondary.  Both replies with the address I would expect,
namely same as the Michigan server.

Thanks, this is fascinating. :-)

Bill
-- 
Bill_MI - Bill in Michigan
Expert Opinions $20, Shut-Up $50
0
Bill_MI
12/31/2010 9:01:12 PM
On Fri, 31 Dec 2010 16:01:12 -0500, Bill_MI wrote:

>Yep, just tried all 12 Comcast servers across the continental US and
>EVERY ONE resolves a DIFFERENT IP pair for aolradio.podcast.aol.com.
>I thought it might be by region - Nope!

I traced out these IPs to see where they go in the Comcast network.
Most make sense but I think I found a bug:

1) IP given by Utah routes through Colorado, not unexpected
2) IP given by Colorado routes through Georgia.  Ooops!

Bill
-- 
Bill_MI - Bill in Michigan
Expert Opinions $20, Shut-Up $50
0
Bill_MI
12/31/2010 9:11:50 PM
On Fri, 31 Dec 2010 03:21:03 -0700, CA was in NJ wrote:

> Now if we really want to have some fun, we could all post what we get when
> we look up aolradio.podcast.aol.com which is the Akamaized server that
> serves up the high bandwidth version of Security Now (among other things).

Using my normal, ATTIS 'Anycast' primary DNS server:

| C:\Users\User>nslookup aolradio.podcast.aol.com 68.94.156.1
| Server:  dnsr1.sbcglobal.net
| Address:  68.94.156.1
| 
| Non-authoritative answer:
| Name:    a1043.g.akamai.net
| Addresses:  69.22.162.83
|           69.22.162.107
| Aliases:  aolradio.podcast.aol.com
|           aolradio.podcast.aol.com.edgesuite.net

And a corresponding 'tracert' output:

| C:\Users\User>tracert 69.22.162.83
| 
| Tracing route to 69.22.162.83 over a maximum of 30 hops
| 
|   1     9 ms     9 ms     8 ms  adsl-69-105-225-254.dsl.pltn13.pacbell.net [69.105.225.254]
|   2     9 ms     9 ms     9 ms  dist1-vlan50.pltnca.sbcglobal.net [64.164.97.65]
|   3    35 ms     9 ms     9 ms  ag1-10g0-12-5-0.pltnca.sbcglobal.net [151.164.102.246]
|   4    10 ms    10 ms    10 ms  ex2-p10-0.pxpaca.sbcglobal.net [151.164.190.83]
|   5    10 ms    10 ms    10 ms  asn4436-nlayer.pxpaca.sbcglobal.net [151.164.251.34]
|   6    11 ms    10 ms    11 ms  69.22.162.83
| 
| Trace complete.

Using the DynDNS "Internet Guide" primary DNS server:

| C:\Users\User>nslookup aolradio.podcast.aol.com 216.146.35.35
| Server:  resolver1.dyndnsinternetguide.com
| Address:  216.146.35.35
| 
| Non-authoritative answer:
| Name:    a1043.g.akamai.net
| Addresses:  128.241.220.106
|           128.241.220.112
| Aliases:  aolradio.podcast.aol.com
|           aolradio.podcast.aol.com.edgesuite.net

And a corresponding 'tracert' output:

| C:\Users\Norman>tracert 128.241.220.106
| 
| Tracing route to 128.241.220.106 over a maximum of 30 hops
| 
|   1     8 ms     9 ms     9 ms  adsl-69-105-225-254.dsl.pltn13.pacbell.net [69.105.225.254]
|   2     9 ms     9 ms     9 ms  dist2-vlan50.pltnca.sbcglobal.net [64.164.97.66]
|   3     9 ms     9 ms     9 ms  ag2-10g0-12-3-0.pltnca.sbcglobal.net [151.164.103.2]
|   4    11 ms    10 ms    10 ms  ppp-151-164-52-211.rcsntx.swbell.net [151.164.52.211]
|   5    36 ms    11 ms    10 ms  xe-0-2-0-6.r07.snjsca04.us.bb.gin.ntt.net [129.250.8.93]
|   6    12 ms    11 ms    11 ms  128.241.220.106
| 
| Trace complete.

Using the Sunbelt "ClearCloud" primary DNS server:

| C:\Users\User>nslookup aolradio.podcast.aol.com 74.118.212.1
| Server:  ns1.clearclouddns.com
| Address:  74.118.212.1
| 
| Name:    aolradio.podcast.aol.com.aosake.net
| Addresses:  2001:4830:1611:0:212:3fff:fe44:c090
|           66.129.99.88

And a corresponding 'tracert' output:

| C:\Users\Norman>tracert 66.129.99.88
| 
| Tracing route to 66.129.99.88 over a maximum of 30 hops
| 
|   1     9 ms     9 ms     9 ms  adsl-69-105-225-254.dsl.pltn13.pacbell.net [69.105.225.254]
|   2    12 ms     9 ms     9 ms  dist2-vlan62.pltnca.sbcglobal.net [99.36.71.2]
|   3    13 ms    10 ms     9 ms  ag2-10g0-12-0-0.pltnca.sbcglobal.net [151.164.102.250]
|   4    10 ms    10 ms    10 ms  ppp-151-164-39-119.rcsntx.swbell.net [151.164.39.119]
|   5    11 ms    11 ms    12 ms  as4323-twtelecom.pxpaca.sbcglobal.net [151.164.248.110]
|   6    82 ms    82 ms    82 ms  tpa1-ar3-ge-0-0-0-0.us.twtelecom.net [66.192.247.226]
|   7    82 ms    82 ms    83 ms  v10.td1.tpa.peak10.net [66.129.96.1]
|   8     *        *        *     Request timed out.


I guess the ClearCloud DNS servers aren't as useful as the first two!  ;)

-- 
Norman
~Oh Lord, why have you come
~To Konnyu, with the Lion and the Drum
0
Norman
12/31/2010 9:48:07 PM
On Fri, 31 Dec 2010 16:11:50 -0500, Bill_MI wrote:

> On Fri, 31 Dec 2010 16:01:12 -0500, Bill_MI wrote:

>>Yep, just tried all 12 Comcast servers across the continental US and
>>EVERY ONE resolves a DIFFERENT IP pair for aolradio.podcast.aol.com.
>>I thought it might be by region - Nope!

> I traced out these IPs to see where they go in the Comcast network.
> Most make sense but I think I found a bug:

> 1) IP given by Utah routes through Colorado, not unexpected
> 2) IP given by Colorado routes through Georgia.  Ooops!

WRT 2): Are you absolutely certain?

Does it appear that this trace is routing through Richardson, Texas
('rcsntx.swbell.net'), to get from Pleasanton, California to San Jos�,
California?

| Tracing route to 128.241.220.106 over a maximum of 30 hops
| 
|   1     8 ms     9 ms     9 ms  adsl-69-105-225-254.dsl.pltn13.pacbell.net [69.105.225.254]
|   2     9 ms     9 ms     9 ms  dist2-vlan50.pltnca.sbcglobal.net [64.164.97.66]
|   3     9 ms     9 ms     9 ms  ag2-10g0-12-3-0.pltnca.sbcglobal.net [151.164.103.2]
|   4    11 ms    10 ms    10 ms  ppp-151-164-52-211.rcsntx.swbell.net [151.164.52.211]
|   5    36 ms    11 ms    10 ms  xe-0-2-0-6.r07.snjsca04.us.bb.gin.ntt.net [129.250.8.93]
|   6    12 ms    11 ms    11 ms  128.241.220.106
| 
| Trace complete.

But I guaranty you, Richardson, Texas, *should* be closer to 60 ms away than
the 10 ms reported in the trace route. ISP network engineers are notorious
for moving IP addresses around without bothering to change the associated
host names.

P.S. Bonus question: How does a DSL circuit in San Jos�, California show a
first hop 26 miles to the east, in the city of Pleasanton, California?

-- 
Norman
~Oh Lord, why have you come
~To Konnyu, with the Lion and the Drum
0
Norman
12/31/2010 9:55:07 PM
sparky wrote:
> On 31/12/2010 10:21, CA was in NJ wrote:
>>
>> Now if we really want to have some fun, we could all post what we get
>> when
>> we look up aolradio.podcast.aol.com
>

 From Uk using Treewalk on localhost

C:\Windows\System32>nslookup aolradio.podcast.aol.com
Server:  localhost
Address:  127.0.0.1

DNS request timed out.
     timeout was 2 seconds.
DNS request timed out.
     timeout was 2 seconds.
Non-authoritative answer:
Name:    a1043.g.akamai.net
Addresses:  82.71.193.210
           82.71.193.219
Aliases:  aolradio.podcast.aol.com
           aolradio.podcast.aol.com.edgesuite.net


C:\Windows\System32>
0
AlanD
12/31/2010 10:48:48 PM
On Fri, 31 Dec 2010 13:55:07 -0800, Norman Miller wrote:

>> 1) IP given by Utah routes through Colorado, not unexpected
>> 2) IP given by Colorado routes through Georgia.  Ooops!
>
>WRT 2): Are you absolutely certain?

No, I discovered the TTL is 20 seconds. :-)  At this instant it still
is strange as Colorado routes now through Chicago (shrug).

Bill
-- 
Bill_MI - Bill in Michigan
Expert Opinions $20, Shut-Up $50
0
Bill_MI
12/31/2010 10:48:57 PM
On Fri, 31 Dec 2010 21:27:06 +1030, Rollo Ross wrote:

> So if you use a DNS server unrelated to your ISP, you defeat that system 
> entirely and wind up with all of your content distribution network data 
> retrieval happening from a server that is geographically local to your 
> remote DNS provider. That can reduce performance for streaming content 
> (again, like that distributed by CDN's like, and not limited to, Akamai).

This is more true when the ISP is smaller, and covering more remote areas.
Less true for larger ISPs. I am actually living in the same region as a
major regional transit hub; ATTW (different from ATTIS), Level 3, NTT, and
others peer very nearby, and my ISP (ATTIS) connects with many of them, such
that third party DNS servers sometimes don't matter. Now, if I was on
Charter Cable, down near Gilroy, California, things would be different.

-- 
Norman
~Oh Lord, why have you come
~To Konnyu, with the Lion and the Drum
0
Norman
12/31/2010 11:42:15 PM
On Fri, 31 Dec 2010 20:40:36 +0000, no nym wrote:

> Also in UK, and on Virgin Media
> 
> Official name: a1043.g.akamai.net
> IP address: 195.245.127.104
>          195.245.127.113
> Aliases: aolradio.podcast.aol.com
>          aolradio.podcast.aol.com.edgesuite.net

(That was using WS Ping Pro, and with DNS provided by the router)

-- 
(no nym)
0
no
1/1/2011 10:14:20 AM
Regulatory Falure wrote:

>You could of course place your favourite CDN aliases (fastest first) in your 
>host file, which is what it is still there for.
>This would leave you free to choose a good non ISP based DNS server if 
>needed.  -:) 

A better solution (IMHO) would be to just block off every Akamai netblock
you can find.  (There are lists.)  Akamai is known to track your browsing
across all the domains that they carry content for and has been doing that
for well over 10 years.  It's kind of like an UltraCookie.

0
CA
1/1/2011 12:09:22 PM
On 12/30/2010 7:27 PM, Steve Gibson wrote:
> Well, it might make "total sense" to that writer, but it doesn't
> to those of us who have spent a great deal of time working our
> way around the Internet's packets.
>
> I've seen all of that stuff on the Net and I've been waiting,
> hoping, for someone authoritative to provide an explanation that
> actually *does* make sense!<g>

Response from "maintenance" in OpenDNS forums:
http://forums.opendns.com/comments.php?DiscussionID=8380&page=1#Item_1

"This only occurs when you are using a DNS server that is quite far from 
your location. E.g., folks in Australia, NZ, and Asia-Pacific in general 
would have problems with CDNs as they would likely be using a DNS server 
(an consequently, a CDN server) in Seattle, San Francisco, or Los 
Angeles. [Since the OpenDNS Singapore server came online, at least a 
portion of this area is no longer subject to problems with CDNs.]"

"Much discussed in the forum here. We generally suggest not using 
OpenDNS, or construct an appropriate HOSTS file if feasible for those 
with only a few issues, in cases where the users experience problems and 
live in locations distant from the servers.
http://www-files.opendns.com/img/opendns_network_map.png (Note that 
Singapore is now online, not planned.)
http://system.opendns.com/ (Server locations and status.)"

' "I would love to hear an official update from an Open DNS" '

"You should then read the blog and newsletter announcements, or open a 
support ticket to ask your question."

"However, there is no other possible change in this situation other than 
having a DNS server nearer to people who have problems with CDNs. It 
isn't a design or software problem, but a network proximity issue."

> Thanks for providing the links that I didn't in my initial
> posting!

You're welcome and Happy New Year!
-- 
Sired, Squired, Hired, RETIRED.
0
Retired
1/1/2011 4:16:45 PM
[for the unabridged version, see Retired's post above]

> Response from "maintenance" in OpenDNS forums:
> http://forums.opendns.com/comments.php?DiscussionID=8380&page=1#Item_1
> 
> "This only occurs when you are using a DNS server that is quite
> far from your location. E.g., folks in Australia, NZ, and Asia-Pacific
> in general would have problems with CDNs as they would likely be using
> a DNS server (and consequently, a CDN server) in Seattle, San Francisco, or Los 
> Angeles. [Since the OpenDNS Singapore server came online, at least a 
> portion of this area is no longer subject to problems with CDNs.]"

Okay.  So this DOES sound as though CDN networks perhaps 
allocate blocks of IP addresses to different geographic regions 
and that the CDN's own domain nameservers, from which any other 
nameservers would obtain the lookup-IPs, are DELIBERETELY 
SENSITIVE AND AWARE of the IP & Region of the requesting 
nameserver... and deliver the appropriate IP-block based upon 
the location of the requester.

Thus, using a resolver that's distant would result in obtaining 
CDN IPs that were also distant.

-- 
________________________________________________________________
Steve.   / Scarce as facts are, supply too often exceeds demand.
0
Steve
1/1/2011 4:31:29 PM
> Okay.  So this DOES sound as though CDN networks perhaps
> allocate blocks of IP addresses to different geographic regions
> and that the CDN's own domain nameservers, from which any
> other nameservers would obtain the lookup-IPs, are DELIBERETELY
> SENSITIVE AND AWARE of the IP & Region of the requesting
> nameserver... and deliver the appropriate IP-block based upon
> the location of the requester.

Which sounds really *crazy* to me

See, I can't see why a CDN should look at the *DNS* IP instead
of looking at the *requesting* (client) IP especially since a DNS
may be running on anycast and this would totally defeat the
whole mechanism; sincerely I don't believe akamai configured
things this way also because it would be easier playing the
same trick by using BGP announcements to find out the best
route for a given requesting client

What /may/ happen when switching DNS is imHo something
different (just shooting in the dark, I've no evidence about it)
that is... open resolvers like Google or OpenDNS ones get a
whole bunch of queries and they, in turn, send them to the auth
DNS servers for a given domain; now... let's say the akamai
auth DNS are "capped" so that an external DNS sending its
queries to the akamai auth DNS will be limited to a max of
n queries / second (e.g. to avoid DDoS and the like); at this
point, open DNS like the google ones may quickly go over
the "rate limit" and their queries may be dropped while an
ISP DNS will have far *less* queries and keep running, this
in turn would explain while, switching from the ISP DNS to
some open resolvers causes the issues; in the latter case
queries sent from the open resolvers to the akamai DNS
will be dropped due to the rate limiter causing issues



0
ObiWan
1/3/2011 9:03:42 AM
"Steve Gibson" <news07_@_grc.com> schreef in bericht 
news:MPG.2786d0a97c93797b288c@4.79.142.203...
>
> I agree Bill.  The idea of different DNS resolvers receiving and
> distributing different IPs was the *ONLY* way I could see for
> this odd phenomenon to occur.  I didn't want to seed the dialog
> with that, for fear of squelching any other ideas that someone
> might have.  But your corroboration of this as the only thing
> that comes to mind fits my thinking too.

Another reason to use DNSBench :)

The "closer" the DNS, the closer the CDN (probably)

Dutch Dave 


0
Dutch
1/3/2011 9:47:08 AM
On 12/30/10 15:43, Steve Gibson wrote:
> That makes no sense to me, and I can't really even see how that might
> actually be possible and/or work.  Has there been any discussion of
> this issue here?

I don't know if it's the case or not, but (in theory) it's possible for 
DNS servers to return different results based on the location of the 
querying IP (presumably via GeoIP location).

Thus, clients may be communicating with a further away CDN server.  Or 
said another way, they may be communicating with a CDN server that is in 
closer GeoIP proximity to the DNS server they are using than a possibly 
closer CDN server.

My preference is to run a local DNS server.  -  Every time I've ever 
performance tested them, the local server almost always comes out on 
top.  -  Throw in the fact of internal domains and I see very little up 
side to not using a local DNS server.



Grant. . . .
0
Grant
1/3/2011 5:04:24 PM
While ObiWan dreams of electric sheep...:

> See, I can't see why a CDN should look at the *DNS* IP instead of
>  looking at the *requesting* (client) IP especially since a DNS 
> may be running on anycast and this would totally defeat the whole
>  mechanism; sincerely I don't believe akamai configured things 
> this way also because it would be easier playing the same trick 
> by using BGP announcements to find out the best route for a given
>  requesting client

Any chance that this maybe more attempts at building behavioral
profiling of users ?  By using the DNS servers to track the
preferences of users.

Since DNSSec by nature won't allow redirection of DNS errors could
this have something to do with making sure that the content you want
seen in a certain area gets delivered ?

So my question isn't over the *best* route but rather the route they
*want* to use.

-- 
Where's there's smoke, There are mirrors.
Give me Free as in Freedom not Speech or Beer.
Thank You and Welcome to the Internet.
0
DarkWolf
1/3/2011 8:01:19 PM
On Mon, 3 Jan 2011 10:03:42 +0100, ObiWan wrote:

>> Okay.  So this DOES sound as though CDN networks perhaps
>> allocate blocks of IP addresses to different geographic regions
>> and that the CDN's own domain nameservers, from which any
>> other nameservers would obtain the lookup-IPs, are DELIBERETELY
>> SENSITIVE AND AWARE of the IP & Region of the requesting
>> nameserver... and deliver the appropriate IP-block based upon
>> the location of the requester.
> 
> Which sounds really *crazy* to me
> 
> See, I can't see why a CDN should look at the *DNS* IP instead
> of looking at the *requesting* (client) IP especially since a DNS
> may be running on anycast and this would totally defeat the
> whole mechanism ...

Do you think Akamai sees 68.94.156.1 when I make a request of them? I don't.
I expect they see the same IP addresses that the GRC DNS Spoofability test
sees:

| Analysis of 4,816 queries from 11 IP addresses  in [ 69.227.255.* ]

That said ...

> What /may/ happen when switching DNS is imHo something
> different (just shooting in the dark, I've no evidence about it)
> that is... open resolvers like Google or OpenDNS ones get a
> whole bunch of queries and they, in turn, send them to the auth
> DNS servers for a given domain; now... let's say the akamai
> auth DNS are "capped" so that an external DNS sending its
> queries to the akamai auth DNS will be limited to a max of
> n queries / second (e.g. to avoid DDoS and the like); at this
> point, open DNS like the google ones may quickly go over
> the "rate limit" and their queries may be dropped while an
> ISP DNS will have far *less* queries and keep running, this
> in turn would explain while, switching from the ISP DNS to
> some open resolvers causes the issues; in the latter case
> queries sent from the open resolvers to the akamai DNS
> will be dropped due to the rate limiter causing issues

Sounds reasonable. Of course, I don't really know a whole lot about DNS,
anyway.

-- 
Norman
~Oh Lord, why have you come
~To Konnyu, with the Lion and the Drum
0
Norman
1/3/2011 9:36:17 PM
Steve Gibson wrote:

> Huh????
> 
> There's a bunch of rumor out on the Net suggesting that users of
> AppleTV, who use other than their ISP's native DNS resolvers,
> are seeing download performance troubles because the CDNs being
> used are somehow keyed to the user's choice of DNS.  Huh???

The DNS system was designed as ONE database, i.e. whichever server you ask 
for a resource (name) you MUST get the same answer (address). That is 
intrinsic to the DNS system. Those who try to have several answers for the 
same name are using the system against its design.

And, DNSSEC does indeed enforce the concept of just ONE answer (one _set_ of 
IP addresses, constantly the same set on all servers) per (canonical) name, 
so in implementing DNSSEC this games are just impossible.

Akamai et al will have to understand and use anycast or BGP routing to route 
their content, not DNS games; if they want to comply with DNSSEC.
 
> That makes no sense to me, and I can't really even see how that
> might actually be possible and/or work.  Has there been any
> discussion of this issue here?

No AFAIK.

-- 
Mark Cross @ 01/03/2011 7:00 p.m.
If Linux doesn't have the solution, you have the wrong problem.

0
Mark
1/3/2011 11:12:16 PM
On Mon, 03 Jan 2011 19:12:16 -0400, Mark Cross wrote:

(SNIP)

> Akamai et al will have to understand and use anycast or BGP routing to route 
> their content, not DNS games; if they want to comply with DNSSEC.

Sadly, I think from their observed behaviour, Akamai et al don't care at
all about how things are supposed to be, or about DNSSEC, so it seems to
be game over. I am increasingly convinced that relying on RFCs, or the
IETF, is a risky thing to do. Microsoft have disregarded standards
almost as part of their business model. So it is no surprise, albeit a
great disappointment, that others copy Microsoft's disregard.

Irrespective of what ought to be happening, one needs to concentrate on
what is actually happening, and deal with that alone.

-- 
(no nym)
0
no
1/4/2011 11:42:34 AM
In article <ifkapg$1n1s$1@news.grc.com>, reply@the.newsgroup says...
> 
> Steve Gibson wrote:
> 
[SNIP]
> 
> Now if we really want to have some fun, we could all post what we get when
> we look up aolradio.podcast.aol.com which is the Akamaized server that
> serves up the high bandwidth version of Security Now (among other things).
> I get 205.241.224.74 and 205.241.224.153 which are owned by Sprint and
> leased to Akamai.  That's not surprising since I'm on the Sprint network
> right now.

From SW Ontario using company DNS servers:

Server:  nv-server.neovision.local
Address:  10.10.2.5

Non-authoritative answer:
Name:    a1043.g.akamai.net
Addresses:  204.2.228.232
          204.2.228.235
Aliases:  aolradio.podcast.aol.com
          aolradio.podcast.aol.com.edgesuite.net



-- 
Jake
  http://www.nymtec.com
0
Jacob
1/4/2011 3:49:42 PM
On 01/01/2011 11:31 AM, Steve Gibson wrote:
> Okay.  So this DOES sound as though CDN networks perhaps
> allocate blocks of IP addresses to different geographic regions
> and that the CDN's own domain nameservers, from which any other
> nameservers would obtain the lookup-IPs, are DELIBERETELY
> SENSITIVE AND AWARE of the IP&  Region of the requesting
> nameserver... and deliver the appropriate IP-block based upon
> the location of the requester.
>
> Thus, using a resolver that's distant would result in obtaining
> CDN IPs that were also distant.

I don't think this has to be the case.

Instead, the CDN, which takes over DNS from the original service 
provider, may simply send different IP addresses out to it's own DNS 
servers, based on where the CDN's DNS servers are located.  I.e., an 
Akamai DNS server in Portland, Maine would have the IP addresses of 
Akamai Edge servers near Portland, Maine.  So any DNS lookup hitting a 
Portland, Maine DNS server gets the same IP returned, no matter where 
the request comes from.

I believe that Akamai, in particular, automagically updates DNS IP 
entries based on continual observation of network traffic (i.e., 
"network close" is not necessarily "geographic close").

This appears to me to be what Open DNS is saying.  Now that we have a 
Singapore DNS server, people in Singapore hitting that one will also hit 
Akamai edge servers near Singapore, based on the IP addresses returned.

Does this make sense?

-- 
John DeCarlo, My Views Are My Own
0
John
1/5/2011 8:28:20 PM
On 12/31/2010 05:48 PM, Bill_MI wrote:
> On Fri, 31 Dec 2010 13:55:07 -0800, Norman Miller wrote:
>
>>> 1) IP given by Utah routes through Colorado, not unexpected
>>> 2) IP given by Colorado routes through Georgia.  Ooops!
>>
>> WRT 2): Are you absolutely certain?
>
> No, I discovered the TTL is 20 seconds. :-)  At this instant it still
> is strange as Colorado routes now through Chicago (shrug).

Akamai continually updates as it analyzes network traffic.  It's 
unpublished algorithms determined Georgia was faster for you (for 
whatever reason, such as congestion or problems) during that timeframe, 
and now it determined Chicago was faster.

A static solution would not provide the level of service needed by most 
customers.

-- 
John DeCarlo, My Views Are My Own
0
John
1/5/2011 8:34:29 PM
On Wed, 05 Jan 2011 15:34:29 -0500, John DeCarlo wrote:

> On 12/31/2010 05:48 PM, Bill_MI wrote:

>> On Fri, 31 Dec 2010 13:55:07 -0800, Norman Miller wrote:

>>>> 1) IP given by Utah routes through Colorado, not unexpected
>>>> 2) IP given by Colorado routes through Georgia.  Ooops!

>>> WRT 2): Are you absolutely certain?

>> No, I discovered the TTL is 20 seconds. :-)  At this instant it still
>> is strange as Colorado routes now through Chicago (shrug).

> Akamai continually updates as it analyzes network traffic.  It's 
> unpublished algorithms determined Georgia was faster for you (for 
> whatever reason, such as congestion or problems) during that timeframe, 
> and now it determined Chicago was faster.
> 
> A static solution would not provide the level of service needed by most 
> customers.

Without seeing his actual trace routes, it is difficult to infer what he is
actually seeing. Comcast has a habit, as does AT&T, of re-arranging their IP
addresses, and failing to update host names; so that a trace route appears
to go the "wrong way", when it does not. Consider the following:

| C:\Program Files (x86)\utils\dig>tracert aolradio.podcast.aol.com
| 
| Tracing route to a1043.g.akamai.net [69.22.162.83]
| over a maximum of 30 hops:
| 
|   1     9 ms     9 ms     9 ms  adsl-68-125-51-254.dsl.pltn13.pacbell.net [68.125.51.254]
|   2     9 ms     9 ms     9 ms  dist2-vlan60.pltnca.sbcglobal.net [76.197.23.194]
|   3     9 ms    10 ms     9 ms  ag2-10g0-12-3-0.pltnca.sbcglobal.net [151.164.103.2]
|   4    10 ms    10 ms    10 ms  ppp-151-164-39-129.rcsntx.swbell.net [151.164.39.129]
|   5    10 ms    10 ms    11 ms  asn4436-nlayer.pxpaca.sbcglobal.net [151.164.251.34]
|   6    11 ms    10 ms    11 ms  69.22.162.83
| 
| Trace complete.

Based on the telco city codes, the hosts are located in:

Hop 1: Pleasanton, California.
Hop 2: Pleasanton, California.
Hop 3: Pleasanton, California.
Hop 4: Richardson, Texas (and a residential DSL host, at that!)
Hop 5: Palo Alto, California.

Do you really think I am being routed from Pleasanton, California, to
Richardson, Texas, to Palo Alto, California?

Hop 4 is most certainly not a residential DSL connection; and, based on
latency, most probably not outside of the South S.F. Bay Area of California.

-- 
Norman
~Oh Lord, why have you come
~To Konnyu, with the Lion and the Drum
0
Norman
1/5/2011 10:38:55 PM
On Wed, 5 Jan 2011 14:38:55 -0800, Norman Miller wrote:

>Without seeing his actual trace routes, it is difficult to infer what he is
>actually seeing. Comcast has a habit, as does AT&T, of re-arranging their IP
>addresses, and failing to update host names; so that a trace route appears
>to go the "wrong way", when it does not.

Hi Norman, thought I'd take a peek and see what I'm getting now.
After seeing it switching back and forth between Chicago and Denver I
fired up my favorite for tracing - PingPloter.  It shows so much more
than traceroute/tracert...

Here is 10 samples, 1 second apart, ICMP.  The graph shows
min/avg/max.  This is Denver.  Next post will be Chicago.  The names
and times make sense for the location.

Bill
-- 
Bill_MI - Bill in Michigan
Expert Opinions $20, Shut-Up $50

begin 644 20110105_aolradio_denver.png
MB5!.1PT*&@H````-24A$4@```V,```$V"`(```!CC]TS````%71%6'1#<F5A
M=&EO;B!4:6UE``?;`043!A;7?'-`````!W1)344'VP$%$PD6A>6,_P````EP
M2%ES```+$@``"Q(!TMU^_```+/M)1$%4>-KMW3N2Y+B6H&&RK:SU7D1%")UF
M-\5<QNQH[NRGA19[";>U+K,JH2(7,?HH/A[!"EX$'@<'(-[\/\LJ\Z"3>#D=
M/`X^L&T```"`S_[\[_?_^4?O8@````SGV]]^]"Y"-[__]H]OWW_\2^]B````
M8%!$B@```/#[I7<!````UK)_OGCDKJ]9T@21(@``0#G[U_`N&MBYZVN6M$*D
M"```T,_%L,\<:]R_)EAB&))(L9%OW]]OGKIRF_F9PO6D6A;[;@4#`"!3]F#A
MX^OF[C#D!6F1XG%XMM0X6C\S<I-U@P/O:A@6X1T`X-:$0;X:YY1+I)D6*9['
M>$*TCFAY``"F%(K;:H2)Y_CB-L;99W.X\0AECFC2'$:RAB3=A>82[_C3D6!H
MN-%,1"B`N8*[U982!X?R=:MI;>*>1-8D9:40S<O-3E-.;Z9R<\F)6$451A8S
MVC,[!7>AVT0``%17]0Z5AS&0F:58I.B-M,R0RPJ_SG#0W3`4#J;F;I5D<T+8
MBR>RK8S<P-1<[FZ;D90WD6A>5CO(Y0QEZB[W?L2A1,Z/=0O'85?:4RBDG(+5
M+-$L``"(>%QX2LZQB9O"E32OA:%U[VBI<;A-BB/-U?2%R4C\8LO4CDN*IV]%
M6E[GQ]2@/=LD"`"`2E)P]M`M?,0VMUX4&J>L<O:Y]H;>$<&692ZR>:6D&@O=
MY"1<0K!>(P``L*HRD>*5N.WZP$]V[D6>69-1Y7I)-1:]U-)[C<%BC0``P,+*
MS_NL.<9K[IF0F?<?Y*4@;#A@F)):I.-BNWJ9RHGK;PTI5<ZR.P,``#B4&5.T
M[AN5STAN7^_\]=ZLFO1\:4WN\E;*C-S-W;S<Y=&4-4EYZZ7/RUTGM&TH4VO]
M4")RVUJ)%V]/92&Y?A$`H/3[;W<_9+S?&-/EP,GMI6WPL&L``++]^]_N>WKJ
MC]_>AUK*GWT&``#`&IK.^\P90```@(DTC12)#MNCS0$`J&K_?,;UXQ%<<BQ\
MZ)YQN'^=5>782IE+<4TC10``@)68\=_QVEVR.<%?E!7\*7.I@4@1```@DS)$
M.V*[-LRQQN/UE6%((D4``("KR@[L73RS?`YDFB_R2DBD"```<$EVF.B-"/.N
M;JQ4SGM%BL(#NC/N_!!24-[EK9G"3GZ8MOMNZG*Y+M=;"0"`M5T)YJK>C.+-
MRSH?'76O2/$($,TI0\ZW4I\$[@9Y9PJ:AUUK@L+4.0^SYTAT)\X^EH26IS<\
M``!KJG$W2=4[5%*OF.3)VQY7Y@M6SHGR7$$32GK7"6V;NMQ<H6#K`0!P*\_`
MZ_RW?89BQS_K5A)EB.:FH%FB+V=2&'JO,<5FUGC&^+PE!P"@#6_4Y2Y,'2/4
MI!!*\UQNO<@;IR12]+@>(7G/2NMUF:Q9CFZ9/QH`@!NZ=:1X9>3ON(SORGGJ
MT0C1+6$B``#W=.M(\6+H$[K9^:+1PK+1R@,``)JY=:08<O$^Z(NK%=\VFJ90
M7\)$`,"=_?';W8^`]XH4C[BGU*->O">OW;/2WKS,%5*CL="VJ<O-$GJ?FW@N
M7.,&'0``4OW[0I>9I?KCXXC_?KLVQWX```#7S2/%;]]_\#Q%``"`=:0\5SON
M7F>?`0``+K)"L<?7A8^O:S:<KJ\*(D4``(`T5OQG1H2[$SM.C4@1``"@O$<@
M6-R=%1Z^MT*;;%^3=;=UL[.B6._F(42*````:4(AG=(9\)DOA%/5[H"E&_Q%
M0T8YP9"Q[FCI.^5)D=SE1%::TZ4-VA,`,)J'\:_L*69A7'#O=#H[.*;HG<]M
M"\\(''JW*O<I@*6>E:@O0/1QB9O8:.8<>N[*;OK>'%.SD]>7GZTHK&RN:=5+
M^:%,VI[1FBJ+5[P]`0`3,<\LAVZ+:1\L^B-%ZTAI'DW="++C0>L\E)H/OFZ6
MNSR@)93$;4]O"[OIAW*4YQ7T)BXWE!!.N9^X\-9]VE.>YT93O.+M"0"HI.H=
MS<7'*2_RGWV^>'PZ)BDQ9_@X__0N]QZ,K>6A-=T-A1R5*2O/:7J'FC0!C;)Y
MW=4T$P:ZHU9*POJI^\,YZ4M2K#-O>VH&)MNW)P"@DH=Q.O@16+)]!GSZL,]-
MP<U.4R3-6Z&\7%?O:#$G@G,']JQCN3L`XQT^D<=@]`5S<XR.[EQL#9-POMY<
MI]>!7RY>ZMG5[@4^UQFY>$,5&`!PQ2-KB;7<>B$$;8_PGX_`.GEE<Q6X]UES
MFB^5?,JO;,I"C:ZWB5#RXE&"E:"0N+=XWC/X[IE][Z5^[H9"?)\15`W>GEOX
MUY$^_>SV!`"@GO)/R2DR2N>]<JO(F-8@Q]J5COIYP[UE3=>>0H'GJ@@`8#I)
M%UF.]90<5[T;J^7+SNHEOM4):X2A/F7QS.M'BS1(P3H.WIZI9<XK,!$D`*`]
MZ=YG\SR:_J$>YLI1PHDV<WG>16`N-^6DTLJM9)VH=:L0NJ/VN=S;PNY-#'FW
M-<BU]M[GD;1^*?=ISZWF3R``0$%_W+Z+?K\/IN--`"L=(Y4WZD*)]@0`H*_G
MT7;TL\\```#HI>>8(@```(;%F"(```""B!0!``#@1Z0(````/R)%````^!$I
M`@``P._]R=O_\9__U;L8````&-*CM+___>_%TVR?1;-<9D%K`"ABI0Y\I5QF
M+`QJVXXQQ3]^^^\:`6BE9!MGT2R76=`:`(I8J0-?*9<9"X.JN$X1````?D2*
M````F;Y]_]&["'7]XE;8G-S/^K,(JTU+I6\F>Z3I%OY8YUQ8HW9EZ_(LGELO
MH`;OGA;ZRE@KS_+-PA2LW:E!%N>?I7;=4/I5V\U;A@/?1QEM)?OE>A(9*GT2
M\H'*/,@-OBM8'18'8+2AW-/8#[&J979LOJ1ZM%64]NSSLRF/?]:?109=CT3<
M_U?%S@&$F(/9UL"V9I-3J-\X7X?6Q&T=/;.Y.UG[R?GBXCYS9F$>"\R=\^(.
MZ4U_\WTIW-H5:4-WH?6ZV=%V9$);>3NN+;![K-V#><84O=V].]AP9:#+/`@)
M693EGB,#D,&*(^4UCQ=6OV$-\#?X^F,E;FQ77+T=TDKYW/^[[/E\W4+DTWIE
M(Z+Q>2)%Z]=/C5S==C279+=R].@5NMQJ\,]5>50&*G$/8]YNT5U-WX&L^EL<
MU]6+I6K'9][TW5V]5YBX<4PQ6,?9!H'01/I<IUA)QM#F%%<NCEPV("1IX(>=
M')OOK-]B.T:#T5#D<>_5._"1;?=\2LYZO0]0EOL=N7*U8FK6O6N/GHX3LL<_
M<V&]JY)J5R>ZSCEB6C!3OD=*M)6&:DS1>UG2E5.BS>Y(EPLY[)6+WNN@@=J4
M7VKE]U??!>LO?`2VF8_N;LG-"]T*]OGN$];F;;3:Y)8)W:MWOMN[^"W8D:([
MD!!JCNP&JG21HKZ$1;*K:OP28CVA7U/N:_U7.-J?"&GBAD([C/!67O03VH?=
M:]3R]DSA.Z*OXT718R)?NI/<,DDMN62K+G6=(@#@#NXVJ`-TE!DI\N4$`/3"
M,0B]W'#?N^,=+0```-#8W__W*)_NHT:B``!@##^WM]Y%0'4O^RMCB@``X*J7
M__/Z_->[%`BR/B#Y3Q.1(@``N.099+S][S^?_P@6A_7\=,[7UN<E?WQ$B@``
M`/`C4L3$]GTOM6%V4@``+"PE4KS]D=0,)O:OK(6AS:UW4]=WBZ%_JV-;`4`]
M<D=*+L4+XY;N97_I75A4I(X4A]AO>[*^+0_#N<*YQ!O>6>^FKN\MAE!"`%B>
MW)&22XW"/`]ZYH)GF/CVX";HE:4\)6=/>)[.DD_).;XYV0N%=Y7K'R^$E>5T
MRC;%^?HL6]*?P@OOFG*[65OI"Q!-RJTI@''(702YU"O,LVO\B!@?9YAXW`QA
MWC:!H9QWJQR?D?5YA3Z^E_V52#&!,BA,"A./0$2(_+9P=*4L8=5V"%4_M([U
MKE`I.1UYG6@3:3XU30$`]+52##=4;Q,OS/OQZ7UX\>>#T'!ESTB1>9\ON1@F
M;N$A+N^[Y@61HX4L\KD2[[O>H,T]RQ\-_JX7+V]-`+BM_:^ST.^],\'BVH@4
M2TH-$Y.,\UM3KIHWTE(6.)I.I>+5+@``K.083ORY_?FVO;WWFA^])?'BJGA*
M3CYW,,Q[;CKT;FB837A76'\6Y_GTLT&BXX71<<?KY0$`*!UAXNGM\?9<\`P3
M?]U?G_]ZEP[EJ<<4]\__CS68U8YYP[*\SD&(&K?/6Z?=^S#,%81WLTM8A.]6
MN."2:$WE=%++8T:?WJ9.K1J`D65TE3?/Y7IAW*(=-[4<8XI'L,CXXDI2[FA)
ML>0=+7`U"$P'/-L.`/BY!1^.0[RX#.YH0:9Q?O@"`$;#^.)*B!21HV6`2#`*
M`#,B7EP#D2(``*B%>'%VW/L,``#J>L:(Q_W1O0N"9$2*``"@!1ZF,R/./@,`
M@$8X&3T=(D4``-`4\>)$B!0!`$`'Q(M34%^GN'_^N[']@_5G=!YAY?JA=Y-R
M9'X1`&MSNT%-5YR7D9QOC;ILSH&FF68-ZSIO=CE"QI?]Q5K!78*6=&.*YB1^
M=YW03YCE.32)B/65$]8/O:M/82-,!+`ZMQO4=,5Y&<GYUJA+V2I<+$REAA6<
MXXN/]QP?QPR!VT>8>+Y&%[I(\9:AH2GC>W)^V30KAP+-I&F(F;,8P-J:15$-
MNE/OK_U>$PVTR?=E?WV+G6(^XL7WUG\VQK-)MH<W3-0DA5(2KU.\ZX#BYLQ?
M)T_EGOV%%WY9#C5Y/`!TM-)T\-[S2+UJ5[MA7]3/QSG"Q`=GRP:0$BG>.$S<
MC.^M<F3^W+OU7SSW!'=2CNV9G=K(KWNW$X"2!ND`:]2E;R??(%/]0."^O\AC
MBHT;Y\X^CJ::'2,Q3'RL%51F7\/A'2,,19;".6A-"MM:'2@`N#(N&;^>4;VK
M(=O4I5)A?FZU+A\TKTWD.L6^GD&Y[M[G>X\FZJ6.DF>,.U[,$0#FM=*/X:'J
M,E1AK-#P^9I[G_M2GWTV`Y)1=J=VW+.9J><WH^N;,9]W!64*0WWA`:`LJZNL
M=*F)U9U6S:5V7>8JS*^^6U484^R+>Y^UW*]*ZA+A7>%[J$QAXX(\`*L+_8IN
MD%'Q7)K59:+"/,-$GK\](/63MP$``.H@3!P6D2(``.B),'%D1(H``*`;PL3!
M$2D"``#`CT@1``#TP8#B^(@4`0!`!X2)4R!2!```K1$FSH)($5#13X?3?N(<
MINH!,!?"Q(FH(\7]\]^-[1^L/T,':>O=_2LAB[STE4M*M4-JHRFKG%J,-O5M
MH'@8.ETC7"GP=)7%1=8GWN"+K^S`LY.MFDNIXF5P9^$[EA`FSB5EWN?C7_^]
MMX]C6B=KQG1KRB-W96M"I%,H"SD%X5W-DHZ-%BK#E3!QP/IFT\^%H%R3"7NP
M*C=,;/#%C_;>>17).$PT4Z1AK2F;CPF="1.GHXL4;W_0:3"9<E(6>5,+EBVM
M^SLX(QVAD%;<;/T_*2EW6_>GO)MOJ%[ZL4QYVU`!E&N&1B-"JT4W5(Y>"W_*
MS1)M-[FUY08?9`P&#?0-H0H>"[K'@@V\O$_B_%>P^/S_8]N+A(G/9'O7[%YT
M\SX?CGYX_7T[4/NO<Z7+LZ=[WQ76S^Y]K`V/+.0E15ACJZ%:%)]C7M-0H77.
MY7*9]74\7RM;PTS66QC]FMZFCI8VM*:0K+N#A3:WRADMH;""_$'('P$P'?E[
M.KLCJGMY5O'SC"1QWG12(L5CO]UO&BQJ#E<G]]W0X=9<:*T?'2,)'6O-Y=%P
MY#KW9-"9M=L.<C\8[26SPT1YV[.HWBX[M06VR@U^4:^QMX*MQ/`ANJCQO7:[
MZWIY)2EU-O_M\>=QTGG_#!;?&%.<34JDB&J\0:<<LG3O1]S">_^45TYZ-ZI@
MF^A#QM!XP#@?4%Z]:N=[_H;9TC_W`1L6R#!F+W&ZWE><8>+'Z_=@\7A]T?58
M$TG4=[1`0?@ZA:(]39KNU]4[BIF1>+/JM\E=&*F-*A[;F;_(KPQ/=M&L&)J[
MNT8H)U`\JM-TXR.X4O$S3-P^[G>V;G#!+'1CBN8MS^/^_JG(/6V:>IUBQA5[
M\G"+V:>X=\_EY9C:&MY\Y7;PUL+;$\GG/N0K03?%N69YM5#N<CM[5ZXQ9J#\
M<-VRI9Y1<N_*5.Y4PH:'4#-&FTOX"$8>GD$I5J=1KZ-K5I>S\*/5Y?K7RAU!
M+#*FB,;49Y_[[[2=I=YNG'=[LC(%X58)>4F-UJAWNED^KZTYZQUJ,<U-1:$_
MH^WL-HZ[K?4BNH*PIC+'T!'(FX[P^4:;1=GFRIT_NC"T!*OJ]>G7NR^P?5UZ
M51F3XCI%8&5##5$``*9#I`B\6S606K5>`";"T[:GQKS/````\"-2!```@!^1
M(@```/R(%`$`0"U<I#@[(D4```#X$2D"*B//LS+FU`X`@`4D1HKW/A[M'ZP_
M0P=IZ]W]J]`F0@K>=3)2*-(.J8VF;*748B1](B,K'H9.UPA7"CQ=95%6@R^^
MI@//3KEQ7=H79G>F[F!.O[FD1(KW[HV/.3S,&2\>G[QS+EOO/@RA].44MO0P
M42AAXT93MM*5E$>H;S;]4P^5:_(81=Q$FR]^M`//+GS[NC0NC#O=LSD9-*:@
M?O+V_G7VYYLI.'MO*"G-MU$_%7*#!MD^PY'L64#D]<V&.EZ;_\]+[=S6*K.;
MEU`O8;YI=TUA6ZL-4]=TJ^"MD3L7=FC#4!M&,_*6,[IA:(50.\@-SKS/:*/L
M3.Y#_:RM49AGF+C]%2S^^1$LOD<2A(G3T46*._,^VP<G>2KW$29ZKUH&-Z[:
M+O2A^@VC:PH1@QD\:<H<K>/Y.JDUW$A.+H"RV)K2AM84DK66"-6WRADM872B
M;<V&;A5P-R-TMHAZ^0@9"1,GI3[[O'\.*([R^Z>UI'.=H7?U(=&QX95K1)J=
MR`A=D>FMA??B0O/`+U<YVGI"?85MK8]569A0"VRE!Q[*ZG4AE+>5YJH"!M3R
MC.W(W^O!O;T_)>?]O"17*,Y(-Z9X?C487&S('0T:DSPR))\?M'K><7IA[VB<
M?DWA+/DL]:J=KW#&.6K`A@7@.AZC^.O^^GEMXO//-ZY3G`Y/R2E)'U)HU@]M
ME9K""-7WUJ)L+.7-7=\^Q6,[_:U(>06NJEDQE#=X=2\G,.9OORGL7T\Z6S>X
M8'SJ.UKNS;T4IOAUBMZSG];F[CI""O4NWWE\O:%;SD4>-!)NI]#?OI-:7\V:
MPBEL(5_ORC6.+LK*NF5+/4-G993=R&Z^H6;47&"0O2W6,_5UBLTZ[;Z%>8:&
MUC0MC"G.)3%2G.QK6)(W'!26U%X_+X4:K1&-&#+>\JX0O0%"6!+=-GJ#12@I
M.7'K?HO0B^@*PIK*'$.=OC<=X?.--HNRS94[<W1A:`GNH\VG7^DG7Y>ZC%\8
M#(6SS\#*SIL_Z/0!]/+S\>>O?]W^C/EP]AEXMVH@M6J]``!M,*8(``#J8EAQ
M7D2*````\"-2!```U3&L."DB10```/@1*0(`@!885IP1D2)P(TQJ`@!(HHL4
M]Z__[NIX+IWU9^C0:[V[?Q5=7[DD-06W%GGMD-IH^C+KWTTM233ELE&4]4'4
M2+;(FM/%CE<*/%UEX>7MTVI_N/5R<=/LM:/6*XDY?=\QK,B$?A-1CRD^C'^W
M=#R[V)SQXO')^^URWWT8HNMKEJ2FX-:B6:/I6TGY[G8M3/2V3+UV*#N==-DU
M>>`BYN*&B7)'42K32KG<(4S<G+F>K9F@,3C./JO4GN(B;RH__;O%:^$=+KU>
MZX*;NV.ZF]CQ":EY!X.%,6.WE82V"K6>N=RM2-*:H:*&5HMNJ!P#%OY4-J:\
M0L;'%-H6$XE."SD1MT^N?:P15)W-[V5_/8/%Y_\?V_[K_CK@!8LOXQ5I!.HY
M6LZN=>)OY27FT.`6FSW=^ZZPOIE+M..0NY+HN]$R:%ACJYJLY2(5[QS=4EWI
M@JW4O+46EFC2"66J*;^PYAZ>SSJTFG?7#=7Q9"T1FL@J9[2$>VQ*[KR/"2NI
MU(W4+O,X86(#1Q#VLC_,B]B(S*:@BQ3-77>_:;"H.0B=W'=#!]'05OHE^G<W
M\4B?;7=.!EEYR>]:04/2ML*[[KC1"%WP7*-9O4J[!RY%F*@*:.SZK\%H^C7V
M)7.8W.JXUHL:WQY_ONPO'R.+_PP6GPM[E^L+(E<OYGT>18,PL9*DDT%MWO6.
MD'4W9JE&*ZV;KWD$3=W#%SO6HJ/B7X>D,?O9G6'BQ^NW9_V.U[_NKS]'"A9'
MBUP'H;[W&0I"#^)]2_CYJ`P3A_H!FMJ!#AXM=2F>/M-!6J]9,4*[M[(`@S07
MBFO\R8[0T\[H#!,/YS6+/%YQ"NJSS_>^3M$],9IZG:+^U.KF.W\:6B*DD%&&
MU-;PYB*W0ZEWS_IZ.V[Y5)%P%:EP84!J2YJM%"I5J4]$H,Q"+EM&1OJJ"1O*
MC1]M,>$KP,%^7M97M<&7R,QWX3W'[0/E7C&)>Z?SN>0(%H<:683EXPM68<]_
MW#.BQ(KN-HIPM_H"R/-S*_:D&X+%8;WLKSPE!\"[\X$RA(D`&N,T],B(%(&(
MFT1.YX.%>Q<$P!T1+`Z+2!$``/1'L#@F(D4``#`$@L4!$2D"`(!1$"R.AD@1
M```,A&!Q*$2*``!@+`2+XR!2!*YJ/TO$",4`@*H(%@>1$BGN=Y_6[WC:G/6G
M<-AVWTU:7TY_\T4&WNP&#"`T!4MJV.M5#GU>V16LU&XMLVOI2A46J#[T,KK*
MB7+9Q,-$56VJG.KGQX31UD)W":I21XK[QU0N-W[4VO%$8FL&=^_D8Z%WK13D
M]>7T-UV8**?0O26%@@G+4YL]NTA7&JW>U'PMLP-&D]%53I3+)AXF%FC8/.<D
MT0=K"FDTH)OW>;]UC+B5F-^L^-07T8EZZ_4UWEQ",RF[)8D6[&BK&GV36:0S
ME^C$S=&DO'^&EH=:25C':IE0BVD^!>5GEU13J[FB6<LK6&5(VMF(F)?GG>1]
MF5PZSI#4ILH7["_/MGFVT/8XPL27_?6-V?]:T46*FW'>>:B=IR'KX"1/2^]]
MM\TT]MYB%\_1&ENU)I67(S"Y8/7Z2C?E[+S<#:WJ*U>S5HYN'A7]7)3KA&HJ
M)&A&J]X=(+J'1$=,-97"3;A[YE9A-RC8:2ASZ7*8$"HXSF^P(TQ\<+%)#^I(
M\=Q/[CJ^F'U\#1VAK<0K[?[64;PEN?NSH@IKH=74UK96+MGO=FF3QCF.4ZK0
MU0+#%AC#"OW,*-O1M0\3-_$PT4";ALTLV_8X@\5CR<^^!;H3=:2(RKRG(^=E
MG4^4>QFYH]1OF_IN8][0>00-6LFMNW#&>80"8UAMHI8N86)?0Q7&\7[2^>?V
MY]OV]BSF<0+ZO"WZ)Z>A*R-2+"GUFY;:&26E/\+77KCOI&_!\O0J>?3RQ.(9
M-:OI(WS#EJ8`\^Y+R-,K@+MAF#A.\:Q;6(X;7-X#Q\\`\0@9B1?K^>BC-3M#
MXG6*C^5.46NN.Y3/MVK6=R\0N9B^M:1L4PAY73DI[%96OZW^7>_E.-'V]+XK
M7*89O:%$<T=+Z!)`=[GF<_$FJZRID*#WA5!3^:X4;\P:O7%GD`,;ZG%OX]LJ
M='3RS8*E,FI3EZJ%^;D-=`\R0XR5O.ROZD@QT7J1(D[C_-9<":T*8"Y#18HG
M0L:RGI$B9Y^!GKK?Z@@`*['.2F^$C)<1*2(9,4U!-"8`U$#(6`J1(@``6!8A
MXT5$B@``8'W<+IV'2!$``-S($2,RQ*A$I`@``&Z'L])*1(H``."^"!EE1(I`
M8<,^&7'8@@'`"`@9O721HC7;UEV/-=8\$!F3A0@S2:2NOSD'_HP4^C9FT@0M
MPOK7YX/1)SMIL#5IL4M588'JX]!X7A-W6J#B&;G3H-?():,P;B/<2O%[7ZPY
M";U+AJ6+%,V=9%=ML1XW+/-.?2:\*\<Z2>MO3I^2D4+?QDQZ5U@_XX-0EE"8
M1&XZ8^X&0(92W_$H[_286]%^P"UPQZ^JM_7F[?1**77ORSE=]?'G1&'BEGSV
M>;_I@.+U#B@UA>CZ[E2DQ<LLI&P6PUJH&7.5"^^=9;52A^5.WRRTFUP,(<`5
MIGB.3FHLE$H_UW9TQF2AD%MLS"8Z,;35>OJYPKTKN(&"IL###J[CHGJ]G/?[
M7K!?'>J7?*B'J=?W3N%E?WW["`W=L](G?>QX!HMSA8D;URGJ6<<>\_LC1T*I
MD9/R\%P\A216?.-&/$-U@B%)Y[CU21W-[HT"HX,?^K'AI$'N4_2#4ZZ35`RK
M%J$])+H+%:D49M?@,IMFW5?+3CNU,%/TX0V\.*'AX1%;(9S@XV/4;:;+'U,B
MQ;L.*!ZR#Y^:*"$OJBB;0G%N\+3I!J4T*6>G)K];MI6BO\6]`YGN5MW[ZS:#
M"@7';^X\"K*VT,^2XL'-N0O5.[N].5UTWTNBA?,;=XX:WT)#AI\!XEO*^>C/
M,<5G8S*FB-NS3A=&SZ1G)%[CW1J-T&:K`2N2Q(V5A3/.(Q08"^O[&WL0-,(6
MBP)3KUD\3SI/=P+Z7[0KWGM`42EU)*/V^MTMW[\H/Y'H19GR\&=&CADK)R78
M;%>,WO#>N`705]+M;L6SKMVAL;O.XM?]-3M,/!S!8N]Z:#&FJ.)>!9AZG6+9
M]3?G8KB,%*Z(YI54^.B[POH9%XQJWA6N^XP60Y-UB'XK:TWEAAD[25(;%BF_
M7-1H8PK?A>5_NBRO<4=WG[K,VXRS<$<0)QI3_-@S*NP5#T8@UW7GDQ$`@,//
MJ2ZV*R5C0'%J+_NK^NPS``#`C=TM3#P0*2(9`XH``-P$D2(``$#$/0<4-R)%
M````A!`I`@``2&X[H+@1*0(``""$2!$``"#HS@.*&Y$B$*6?.*'4%`M]IVK(
MRYWI)0`LZ>9AXI8VF]_^UX.Z[VG_Y"X4-G$W%S;13%0E9V<E+F='^[1LGU[.
M>65Z%\0N$G"%.;%DM.N8)9=M@$ZI394'Y\ZS-]',>S7H(L5CTN?CW[UVF,\&
M^)B5Q)IS[%P8VL3\\V'0K*]<(I306V;:ITO[=#3@PR\'+!+F8GYAHUW'1+ET
M[Y3:5'E\YJ3,O^ZO^_:8:.:]&ICW.5-T1KO05SVTH3QQL)SF%IB0MVKUY5P6
M:!\A$K7FMG93<]<T)X]VLPZUY[FR,*VV-:-Q*&MSM="4UJ$5O#45RAQ:\RRP
MLAB:QH\V"!9S[#_>KV?!#[UO+EVTJ?(LCF#Q\:S]1YCXLK^^W?@$M"Y2-(<2
M;[?#!`TXG[KW&%GC>R['/0NTCQ7;;8%HS]L.T;A0V9[FZU#69M0E%$G.PBUD
MM*::^GK7#+6PMQBASTCX+-P&P4K:?*PKY3)C809QA(D/KI?A[+/2<1BS+M?(
M.$U0^]OHEJ=2CE9K:-I'<[V+%0%<O#XF5*3L]LDNDG7*6Y.R&QLILU:V\PC7
M'GEKW;=(&-^YSU3MZ+KDXNU(FVE3Y8G\%2:^CRG>=S3QP-EG+>^XR.#JA8G"
MZ4+]^5_9]9)KSB\GY5*IQPRUIW=X+"G4;ER15-Z!3,X=0Y`Z6C]=+KT.-&VJ
M/)&7_>7M\?9S^_-M>_MX?>M@D:?DI)&_1?JCN&9]97E"277YPE_)M&J!E>VC
M_$2RAQ6M84+-)I4:)+LBM8N1U$3`MN+)XD'"M4&*T=X1)IY_FC>XW!/7*6I9
M0QWF43QT/G%+^:9Y+X:++CEYRQ,Z`%\4NNIYI?:1;Y>1[\"(UEW3GN9;^I`Q
MM*9YGX=;O-0""YO(B<LI"&6P5LXH,#`%QM1'X-[I?/-[GS]ZVPK[Y..V$25N
M(_4:1WI_&@%8R<_MUO'33;SLKURG"*`NQO\`8%[OD>)CJW`Y%$<$K&Z$NV&F
M<.>Z`\#LWN]HX;)Q`````````%KOHXF__\\_>A<#````8_GV_0?/4P0``(`?
MD2(```#\B!0QM&_??SS_]2X%```WQ?,4D<`-VKI<Y*HIQK$.U^`"ZS&_W=Y?
MDD6^^.US<3-JW(.UJ3*F0Z2(9&:G]OS7ON\P.[)0[O1HP)+D6*K4*8@NN;A1
M8\L.MDV5,2,B113C[6B\OYB??UHOMO"OZJ3<CP3=](6,B"F!69C?;N^[6XEO
M]`BY--:FRI@4URFBC+,K.?YMNH#OZ)[,]=UT,HJAR0C`7-H,L*V4RXR%P8`8
M4T0R,]*ZV+\4[YZ23D;3.0*SB$8S1<:]!LFEI395QM2(%)',/*7;NRP`[L*]
MJJ]&%]0QEZ-K;7_2HTV5,2\B1>0X>S0Z%``-F%V-^TNUU&_7[KFX;]76ILJ8
M&M<I(E/&-7^I'5_MCI*'-0(8$R$:QL&8(O*9(XON>9.CCS.7:V[T2UU?J>"U
ME0!0"3T5!K1O[(Y8&C_-`0#(\SR&<O89````?IQ]QN(8300```````````":
MX(X6````>*QV1XMRHN':632N4:^R35<>90G'+S8`8!`C'S)*E4V*%*W'XPF/
M*3Z7'^N$UG2G#)*K9"4EI#R7CE5HEO4Y?<O(>U'!YS5N/,<;`&96*<:H<5P(
M%;72,2AX[[-YI#\.J*&3U-XGA48K$#W`6ZD=SW:VRC8ILV&[9%V;M?-L`^]%
M<JFN5!D`,`NSZRY[4*AQ1/`6M=Y0Q9<QQ;QHVFT%;RM;2^0_4PD#5T+H;:YC
M+I<3MU8+Y24724C$FV:H+M&JN:7*;B)--;.-L!?)#2BW%0!@4M;AQIRKUCW2
M*0_$WA2BX4&I*H02%T(1JYSF5E_&%,U!$??$7)>Y+KP3EEME,(=SK#_-B-[[
MB\$:6!*BD]`/#CDOH0RAE>5UO&L*5;,:Q[O.%@O4HM4)[:,3[46A3US_43(9
M#`!,[3Q@R=V^YJ"P!<8RA&.T=9"RRB8<IH4CFB8O*T'WW5^LE;P9>//;`@=%
M=RPT]=AI;J6,2$(?=A%NK"-_G!E%:C]&99WMK7?.5-B+Y.(5+$_>7I2$L\\`
M,#OO`6NK?(R6KYL2MO*&(E>.06?<927RSTC1._@D)U=J->56PFABD7R]V;G-
MX@W,HX&@O%KW"Q8UOS9JT(?^&47R;D4D!P`P12^CUT='>;E[,Q56\YY[W,H=
MX*P&^<5ZPRVH&6-N@?'/+3QHZ5TM^J?54FY<[SWQY_YI)BZ?*Q1./7L_L-`Y
M>J'1-8F8?T8_;^^:UD(A:Z%L5CI73JW.LA?I&]E;!<X^`\"\A*-YWF54RI-U
M;L3BOO9*.I!9>0GAP>8+4M=_\K8^Q%Y[M*EQ[69IS-1RSE(O`$`-=SL*?%OL
MR=M7+/S9'S<Q-:Z=<K2UKX4_=```BB@PIO@\W+X]_NQ=$0```&3Z?[_]7W<A
M8XH````("D:*PF,A>?(P``#`'?@C1?<IS>=E9TGW_`(``&!>_DB1R_P!``#`
M=8H```#P(U($``"`'Y$B````_'[Q+O7>O!*=D`T````K\4>*[IRVPI\```!8
MTB_7DS"=#_C^U[_]&TM8PA*6L(0E+&$)2V99XL5L?@```'?';'X```!(0Z0(
M````OY+7*9KCEO_ZMW^S_NQ=4P```*0I&2FF7B,)``"`D:6=?3Z>I'B\.%];
MGF&B'"`^5SC^G:_=Y0```.@NYSK%XXG<FC5#D=\SE#Q.3Y\OS.6]VP0```#O
MDB-%.4PT!Q2/L,^Z8%&@7Q,````-I%VG:,:(-69J.0<:>S<+````TN]H,2]/
MM()%*\A+O:^%`44``("AI$6*\JEG*R(,!8CFZ6GS!4.)````0^')VP```/!+
MODY1./L,``"`Z;SLKZ&@KN399P```*R$L\\```#P*WGO,P```%:2_SQ%````
MK(VSSP```/`C4@0``(`?D2(```#\B!0!``#@1Z0(````/R)%````^.5$BM^^
M_S"?J@@``(`E)4>*QX1^U@30````6`]GGP$``.!'I`@````_(D4```#X$2D"
M``#`[Y?4#<Y[69XO>A<>````%25'BALQ(@``P#UP]AD```!^.6.*[I,47_;7
MWA4!``!`IM"UA07./A_/XJY7[I5.=B]6'6HTOL6J0XW&MUAUJ-'X%JM.WQIY
M)U49[NSSM__\\?P771Y:;02:<DY4';-&1SD7J)%5SI5J=)9VF>JL]P$M4"-Z
MN?%K9)5SI1J=I5VF.H-_0#ECBO4\F^#W__4/\X5W>6BU$5@?ZNS5L6IT%F_J
M&IG6J]$6Z$`GK4ZHA`O4:-Y=CEYN_!J9UJO11B_7MD;#C2EF$'XPM7?]\QNJ
M.D5JM$WUVV[V&N5U(L-6YTH[4*-*UNL3UNNWKQNY1AF]W,C5R6Z$9C4::TSQ
MB)HW\WO[=^V&VPP_'=:HSI>"4:.1:N0IS\S5.2NU+=0GT,M-49UE^H3U:D0O
MU[Y&!2+%@M==NH.K`WZB5RQ0'6NG5-9HY%]RB]7(O-SJ69?9J[,YO>'L-<KN
MY8:MD66!ZN3U"2-;K$9YO=S(QHE\O!'=Z&>?1^Y-;E@=][>+ID8C?YD7J]%1
M*K.OF;HZH=)2HY'-7IV\/F%DB]4HKY>;RV@UVK?!YERQQF#-W]_6\LW92T;H
M=ZS"S%X=JSSN==^:&@U8*;=VR]3H+-XRU<GX$E&C!N7?+O1R0U5G*]'+#56=
M4.V6J=%9VF6J,W*H\.W[C^$BQ9QJ#'G9`=4!@)M8K]]>K$:+5:=EC9Z1XNAG
MGP$``-#+^YCBX_'H70P```",9=_W]WN?__CMOWN7!````,/A[#,```#\B!0!
M``#@1Z0(S.W;]Q_"GQU+,J;40@Y5J:,P98MDIC94995E'L2`10)*(5+$4I[]
M]?&O=T$*5*1-+E:+Z?-UM]74):]>5EY]/U^YUNZ[J>L+^8:>:$:TU[T=GA_-
M+"T/I!IKWF?@HJ._GOT1H2V=;76T6U+36=M6*N%0'ZA9&+=@[KNIZ_>N7SNW
MJBPP-2)%+.O\B7_^W#>/RN=;UI)SH;N.FW)H97<%[SIF)!$JDOQNM.);8CAR
MEDHH_Q8[S&OJ$FHW9:PO)R(7/NGCL,@%2XU^O.M[=SRK390M'&H*^77H1>IR
M;Z7<!I<_K-`Z2>T0_;CE'2/TI]6K\#,5JR)2Q,I"!S!YX&<3HROERIJQ)7-A
M-`6YP&ZM-T5<&&TZ98XFN36V6,CBEMF,%=SFTC2=M_":""E462M$2'I77E_Y
MD2E;>"NT,Q01*DG>A[55V-.VV)?=S$).!U@)D2+N2'E96.T$O:-$UPOCYJ(?
M04ER95M-F[@+Y2K4R-I+#A%2`XC&D8<R\=`^D[I\$%<^;N#FB!1Q.\KAL;PK
M]O+6B1:IWE'M2LK72W4]!?U@Y_6M&G!/FZ((&A/(QKW/0$2#P<5*A3F-/-AS
MO4VZES/USO'H^E4_J6@AS;WERFM]@[0D?X(`7(PI8BGNA8,N]WD6\A+ALKGH
MRLIUA#2/^Y&M;>5'<EP_*:QI-,V:5FG-NGCK)5='3C"I\/)6PKOZS]']I#3K
MRWM==.^R6G@3=X;&=UXK=TMOXWNW+;ZGN6GJ-VS3AD`7^\:P/&!(ZNYG.3:4
M+><LM5Y,1K/+F[2,%//2'_S:QR)U!`;WW+$94P3>)8W#U1BT&]\]:SV.B6*F
CBV;<TV[RT0````#`/_U_S&5Q!!#1+G<`````245.1*Y"8(*T
`
end
0
Bill_MI
1/6/2011 12:16:13 AM
On Wed, 05 Jan 2011 19:16:13 -0500, Bill_MI wrote:

>Here is 10 samples, 1 second apart, ICMP.  The graph shows
>min/avg/max.  This is Denver.  Next post will be Chicago.  The names
>and times make sense for the location.

And here's Chicago, seconds later.

Bill
-- 
Bill_MI - Bill in Michigan
Expert Opinions $20, Shut-Up $50

begin 644 20110105_aolradio_chicago.png
MB5!.1PT*&@H````-24A$4@```V,```%8"`(```!1<;,9````%71%6'1#<F5A
M=&EO;B!4:6UE``?;`043!Q0@:2,M````!W1)344'VP$%$P@GS2"]A`````EP
M2%ES```+$@``"Q(!TMU^_```,+])1$%4>-KMW4F2Y#AV@&&RK4Q['2(C%IUF
MG<L\AFZDTGVTZ*6.T+WK,JM:9,0AM->&\@AFL!`8'AY`3`3_S[+*/.AT3$Z"
MS\$!RP(```#XK(__?O_7/WH7`P``8#A?__:]=Q&Z^?VW?WS]]OTOO8L!``"`
M01$I`@``P.^7W@4```"8R_KQ8LM=7[.D"2)%``"`<M;/X5TTL'/7URQIA4@1
M``"@GY-AGSG6N'Y.L,0P))%B(U^_O=T\=>8V\R.%\TFU+/;="@8`0*;LP<+M
M\\?=8<@3TB+%_?!LJ7&T?F3D)NL&!][5,"S".P#`K0F#?#7.*9=(,RU2/([Q
MA&@=T?(``%Q2*&ZK$28>XXO+&&>?S>'&/939HTES&,D:DG07FDN\XT][@J'A
M1C,1H0#F"NZGEI0X.)2O6TWK(^Y)9$U25@K1O-SL-.7T9BHWEYR(551A9#&C
M/;-3<!>Z300`0'55[U#9C(',+,4B16^D989<5OAUA(/N!T/A8&KN5DD6)X0]
M>2+;RL@-3,WE[F<SDO(F$LW+:@>YG*%,W>7>KSB4R/&U+N$X[$Q["H644[":
M)9H%```1VXFGY.P?<5,XD^:Y,+3N'2TU#K=)<:2YFKXP&8F?;)G:<4GQ]*U(
MR^OXFAJT9YL$`0!020K.-MW"+?9QZT6A<<HJ9Y]K?]`[(MBRS$4^7BFIQD(W
M.0F7$,S7"```S*I,I'@F;CL_\).=>Y%GUF14N5Y2C44OM?1>8S!9(P``,+'R
M\SYKCO&:>R9DYOT'>2D('QPP3$DMTGZQ7;U,Y<3UMX:4*F?9C0$``.S*C"E:
M]XW*9R27SW?^>F]637J^M"9W^5/*C-R/NWFYRZ,I:Y+RUDN?E[M.Z+.A3*WU
M0XG(;6LE7KP]E87D^D4`@-+OO]W]D/%V8TR7`R>WE[;!PZX!`,CVU[_=]_34
M'[^]#;64/_L,``"`.32=]YDS@````!?2-%(D.FR/-@<`H*KUXQG7VQ9<LB_<
M=,\X7#_/JK)_2IE+<4TC10``@)F8\=_^VEVR.,%?E!7\*7.I@4@1```@DS)$
MVV.[-LRQQOWUF6%((D4``("SR@[LG3RS?`QDFB_R2DBD"```<$IVF.B-"/.N
M;JQ4SGM%BL(#NC/N_`BE(*0<O?L[^A1K38'EF?'T'XR6F8<U`@!P)IBK>C.*
M-R_K?'34O2+%/>HRIPPYWDI]$K@[V?2^Q(W2CC639IT1_E3.I">74_Z4M5R_
M/@``MU+C;I*J=ZBD7C')D[<]:H1!I8;?Y'3<*%"9XV.U4#CH3<&[/@``-_0(
MO(Y_RT<HMO^S;B51AFAN"IHE^G(FA:'W&E,L*"].4CY[W)JY6)]XC>B-YZ4#
M`!#BC;K<A:ECA)H40FD>RZT7>>.41(H>J?%0QFGET%E@^4RQD)$<)IZ)]J)E
M!@``L[IUI%ADM&R<NSJ$*Q2)]@``0(9;1XJUKQHL2\Y+.?0(``"@=^M(,40Y
MZE;\)I6,T;YH&80T"2@!`)#]\=O=CY+WBA3WV*C(Z=?C5*]U"GL/^-SSVJ'E
MIB)/><Q+TUSGB""%,GO7/UE4``!&\]<;/Q7NC_<C^]OMVASC`0``7#>/%+]^
M^\[S%`$``.:1\ESMN'N=?08``#C)"L6VSPNWSVLVG*ZO"B)%``"`-%;\9T:$
MJQ,[7AJ1(@``0'E;(%A<G14VWUNACRR?DW4_ZV9G1;'>CX<0*0(``*0)A71*
M1\!GOA!.5;L#EF[P%PT9Y01#QKJCY6O7.XR*Y"XGTK>"5T1[`@!&LQG_RIYB
M%L8%UTZGLX-CBMX9AQ??(W6*S(F7QWU28..IZD+911]AZ+:GMX7=]+TYIF:7
M43RA/%8ZUN,5DYZV.&M[+NH=JFQ[`@`NQ#RS'+HMIGVPZ(\4A1F$W0->QX/6
M<2AU)SAN0![04LZ;LK_VMK";?BA';P@B9)>ZOC+WDQO#K.VYI.Q0!=L3`%!)
MU3N:BX]3GN0_^WSR^+1/[&'.8G+\Z5WN/1A;RT-KNA\4<E2FK#RGZ1UJT@0T
MRN;U3N(2K7XTL,M;/REJ.2:&2?W4K.T9B@6KMB<`H)+-.!V\!98L'P&?/NQS
M4W"STQ1)\U8H+]?9.UK,R>+<@3WK6&Z.[EC'>&$<*^^<LC?'Z.#3R=8P">?K
MS74N<>`?H9PSM:=9HPL5&`!PV+*66,NM%T+0MH7_W`+KY)7-5>#>9\UIOE3R
M*;^R*0LU.M\F0LF+AS56@DD#9M'US9'@T*5U5FK1BP[SAAOG:,_%=^U$7GL"
M`%!/^:?D%!FE\YZM*S(&,\BQ]EI'??G*N;SAWK*NU9ZR:2H"`!A3TD668STE
MQU7OQFHABJTQ)FJ]6SP:D.]*/K]^AH)UG*P]\YJ:"!(`T)YT[[-Y-:'^H1[F
MRE'"B39S><;Y2B\WY:32RJUDW8+M5B%TA^Q^\VSH.2_N&&UJ8"1\?476+V76
M]EQ2=B@`P%#^N'TO_78?3*]CU4QG#*/5F:RR#=">``#T]3C:CG[V&0```+WT
M'%,$``#`L!A3!```0!"1(@```/R(%`$``.!'I`@````_(D4```#XO3UY^[__
M_C^]BP$``(`A;:7]^NNOQ=-LGT6S7*Z"U@!0Q$P=^$RY7+$PJ&W9QQ3_^.V?
M-0+02LDVSJ)9+E=!:P`H8J8.?*9<KE@85,5UB@```/`C4@0``,CT]=OWWD6H
MZQ>WPN;D?M:?15AM6BI],]D]3;?P^SK'PAJU*UN71_'<>@$U>+>TT"YCK7R5
M/0N78&U.#;(X_BRUZ8;2K]INWC+LV!]EM)7LE_-)9*CT3<@'*O,@-_BF8'58
M'(#1AG)+8SO$K*;9L-E)]6BK*.W9YT=3[O^L/XL,NNZ)N/^OBHT#"#$'LZV!
M;<U'#J%^XW@=6A.WM??,YN9D;2?'BY/;S)&%>2PP-\Z3&Z0W_<6W4[BU*]*&
M[D+K=;.C[<B$MO)V7$M@\YB[!_.,*7J[>W>PX<Q`EWD0$K(HRSU'!B"#%4?*
M:^XOK'[#&N!OL/MC)FYL5UR]#=)*^=C^NVSY[&XA\FF]LA'1^#R1HO7KIT:N
M;CN:2[);.7KT"EUN-?CWJCPJ`Y6XAS%OM^BNIN]`9OTMCO/JQ5*UXS-O^NZF
MWBM,7#BF&*SC;(-`Z$+Z7*=82<;0YB6N7!RY;$!(TL`/&SD6WUF_R3:,!J.A
MR./>J[?C*UON^92<^7H?H"QW'SESM6)JUKUKCY[V$[+[/W-AO:N2:E<GNLXQ
M8EHP4_8C)=I*0S6FZ+TLZ<PIT69WI,N%'/;*1>]UT$!MRIU:N?_JNV#]A8_`
M<N6CNUMR\T*W@GV^^X2UZS9:;7++A.[5.][M7?P6[$C1'4@(-4=V`U6Z2%%?
MPB+9535^"3&?T*\I][5^%X[V)T*:N*'0!B.\E1?]A+9A]QJUO"U3V$?T=3PI
M>DQDISO(+9/4DE.VZE37*0(`[N!N@SI`1YF1(CLG`*`7CD'HY8;;WAWO:`$`
M`(#&^O:_K7RZ6XU$`0#`&%Z7E]Y%0'5/ZS-CB@``X*RG_WI^_.M="@197Y#\
MIXE($0``G/((,E[^\\?C'\'BL![?SO':^K[DKX]($0```'Y$BKBP=5U+?3`[
M*0``)I82*=[^2&H&$^MGUL+0QZUW4]=WBZ%_JV-;`4`]<D=*+L4+XY;N:7WJ
M75A4I(X4A]AN>[+VELUPK'`L\89WUKNIZWN+(900`*8G=Z3D4J,PCX.>N>`1
M)KYLW`0]LY2GY*P)S].9\BDY^YZ3O5!X5[G^_D)864ZG;%,<KX^R)?TIO/"N
M*;>;]2E]`:))N34%,`ZYBR"7>H5Y=(WO$>-VA(G[S1#F;1,8RG&WROX=6=]7
MZ.M[6I^)%!,H@\*D,'$/1(3(;PE'5\H25FV'4/5#ZUCO"I62TY'7B3:1YEO3
M%`!`7S/%<$/U-O'"O!V?WH877S="PYD](D7F?3[E9)BXA(>XO.^:%T2.%K+(
MYTJ\[WJ#-O<L?S3X.U^\O#4!X+;6GV>AWWKGQY_$BQ,C4BPI-4Q,,LYO3;EJ
MWDA+6>!H.I6*5[L``#"3?3CQ=?GQLKP\>LV7[>7+^G;NDGAQ2D2*^=S!,.'<
MM'+T47.*.9K(R(ZKI(^21\<+O>..I6I]N08$@+[V,/'P"!/?;VIYBQ&)%Z>D
MCA37C__?]:AJWK`LK[/S1H'FN^8-9>[*\KO9)2S"=RM<<$FTIG(ZJ>4QHT]O
M4Z=6#<#(,KK*F^=ROC!NT8Z;6EZ)%V>4<D=+BBGO:(&K06#*L!\`#.AUD1Z.
M0[PX!^YH0:9Q?O@"``;$^.(TB!21HV6`2#`*`!=%O#@!(D4``%`1\>*E$2D"
M`(#JB!<OBD@1```T0KQX.42*``"@*>+%"R%2!```'1`O7@*1(@``Z(9X<7!_
MT:ZX?OR[L?6=]6=T'F'E^J%WDW)D?A$`<W.[04U7G)>1-^NJ=5GZ=>/-&C;D
M$2,^_CWBQ3UD/#RM3]::[A)4I1M3-"?QN^N$?L+4PZ%)1*Q=3E@_]*X^A84P
M$<#LW&Y0TQ7G921D7:DN2]<PL4W#1KGCBQ_S2O^<#\9\C39TD>(M0T-3QGYR
M[&R:E4.!9M(TQ,Q9#&!N;E=9*8*QNM,:H9(WP5[=>+.&#7E:GU^,\\YFO+B\
MQR"/;\`*&37IH(C$ZQ3O.J"X.//7R5.Y9W<KYB]+9U+V@2:/!X".Y#,SE7+<
M7Q0?62R>YLGR6&?/FA7OZ?-)Y\/V\_]O17N4Z(GQD.92(L4;AXF+L:LH1^:/
M;D7??WEW47V.[9E=Y\BO>[<3@)+:AXF+<P@HF^PX7;H[0M&L>,&QP/<(<EWV
M,<4M.J;8L,'N(N6.EOZ;\65L'Q9UI&+MBADI=*_FL*\!3*-+F'@'?9LQ%"9^
M69]?MQ][F+A\7+.8D0[.T$6*A(DZJ=>79(P[GLP1`*YKIC!QJ-[;V["]"_4S
M3+2N38P&BRA.??;9W&8NN5>>XI[-3#V_&5W?W"VC5SH+*5RWWP2`*+>KC':>
MV;D<W6F-"UJ\:7;LQJUF['L-CW7OL_4N]SXWQKW/6II;P^0EPKO"?JA,81GX
M)#4`%-'RWN<&&76_XUC.MU=A]J'$+EG#2WV=(@``0$V$B0,B4@0``/T1)HZ)
M2!$``'1&F#@L(D4``-`38>+(B!0!`$`WA(F#(U($``!]$":.CT@1``!T0)AX
M"2GS/@,WECU_]U!E`X`1F,_6QN#2YVBY\?%H?V"]]3#])3;GBCN+P!)^HJEY
MR$]*7[FD5#OH$XR6X?Q,AK7KVT#Q,/1RL>.9`E^NLCC)^L;;[/@U<O&F:1UH
M6JK4L-9T?!]+B!$O(V7>Y_U?_ZD@^]AW(3,HV3ZX\V-ZW]T,H2SD%(1W-4LZ
M-EJH#-D%&[.^V?0=L7)-(B?,RMJ[V^SX-7+QIFD=:%JJU[#63,UNX(C!,9N?
M2H-!BST+Y0Z9-[5@V=(NSG!I1HY"E:WAU7W-X_^:-G%3.S[KCOA:>0GUTH]E
MND4UU[3:,'7-T*!U:#5A3;D-HQEYRQG]8&B%4#LLBN%SXN,[N.)/P5!%K"5]
M1\<K->S3^ORR_=B#Q>U1Q64K$B;NR79HIEM*N4YQWX3NVA5;!R=Y]G1AZO>E
M:`?A/5G0X$2&&U=Y:U%\CGE-0X76,8,GH<SZ.AZOE:UA)NLMC'Y-;U-'2QM:
M4TC6W<!"'[?*&2VAL(+\1<A?`5!#\:[,I+_HZ**>WB])?#\EN6WY9Y+034JD
MN&^WZTV#1<WAZN"^&SK<F@NM]:/[4^A8:RZ/AB/GN><LCJR]XX)6>X8^*W\+
M^C;1?-8[8*GOST*7!Y1KXY(Z7HK@+LG^@=2E"K@MY<_+DRDOXL^VZ]H'_];2
M8XJ]JW4CW/L\!&_O((<LX_0CRI&A\^]&%6P3?<@8&@\8YPO*JU?M?(4SSE$#
M-BR08<Q>HJP]3-RO37Q=?KSUC&N!8)%3SRVI[VB!@G#HS;Z?PWMH%RYK2TJ\
M6?7;Y"Z,U$85C^VLJ]3UM:C>4B,5(]3@R@(,TEQ`ACN$B3OS%I;7[<>VK.8-
M+AB?^HZ6>S\EQSUMFGJ=8L9E+O)PBW6E?Y$<4UO#FZ_<#MY:>'M,^?R[?"7H
MHCC7+*\6REUN9^_*-0X&RB_7+5OJ1>N;<_.^<J,2/K@+-6.TN82OX";'W9NS
M.HVJ5Q`>*N42[<9;JM>PU@CB6["XKJ\+@X*7\;X=5-@@MWM&E+BLZ7_?3U]!
M`(V]+ODGD9F=Y2J>UF>N4P1F-N6ME`"`9ICW&7@S:R#U\>C<.6L'X*)>MQ]?
MN'_Y(H@4`0!`:P2+5T&D"````#\B10``T`'#BI=`I`@``/H@6!P?D2(```#\
MB!2!P@:9.&208@"`C&'%P25&BO<^]*SOK#]#QV/KW?6SZ/K*)6XBJ6GFM4-J
MHRE;*>G=U))$4Q:*<::YLA6?`_!RL>.9`E^NLM"+=G0U<EGJ;%3>D@_2Y]1H
M6'<>OWT)P>+(4B+%>W>\^Q07YL1QQY/JO/NY^^YFB*ZO6>(FDIIFLT;3MY+R
MW>5<F.BF/&!@H7\(HG)-GJJ("40[NAJY+-7"1/>(,$Z86*-A7[87,UBTIH0F
M6!R3.E)<;SKC\\_:5YX)S3OK<71)Z@IE&\0=+FV6NZ:^[ICN(G;!FM2$E-W7
M^C*8JX525JX9&LD.K1;]H'*X5_A3'M6.#GN'1ERB'PQ]%E?7IJ/+Z(%3>0\K
MM8\U^BI7*L;3^GP$BV:8>'@$BW/'BT\7K)UN-K][AXD_V^#SK&CR[.G>=X7U
MS5S<WY?1)4H%9WRWQE9/%JP&MU1GBF=^4%E?;\N$/F*]*Z0LK.E^*OHU>;?2
M8PL/)6LM\2;N+6>TA,(*\O<KE`%S*]BMM6>5?*@NU"QAV5+MH=+3^DAS??K\
M4V[[O`X&H9[W>35>C+4E-Z(Y,AW<=T-'UM"G]$N$`GO/)J2F$^7F8K58Z%UO
M"96?C;[K#B95JN^Q,6B:=+3#0*A2'?/-WC(9/KRG87^L:GA_3`Y5EQHA[,OV
M8Q]-?`2+]ICB1X#X6*=WU6NY8A"LBQ2/+>2N86(#-483W:&C&I+.60A#2JF?
M%=[U#IL542_ECGI5RLW7/%BF'IE&.*P"9UPWY-4[PL3EXYI%*UA\G3=&/%J@
M=Q&2\92<DH2CK/<MX>>C,DS4'->;=3K90<:8W:*^.LH!Q>ST!PE)FQ4CU)+*
M`@S27,"E5=J/K-#0NL$%8U*??;XW]U*8U.L4HQ?3F+NE>_XTM,1-(31.HRE#
M:FNX-W='V\%;YM"E>YK/>D,T^68]X2I2.;6DVP#;7SZES-&M0NJ]C9MS1[^R
MIL('=Z&]1G-:/_NSN!9K5ZVTHX6ZTX(_:T>[PK)-P[JWL+A+,)KW[:#")KIQ
MEAJW,>:8Z-PE!]#=ZU(RR/NR/D]_ZOF*GM9GQA2!VQEJ)`,`,#(B1>"LR\5;
MERLP`*`7[F@!```]<>IY9$2*````\"-2!```W3"@.#@B10```/@1*0(``,"/
M2!&X.R8U`=`+IY['IXL4U\__[FI]9_T9.LI:[ZZ?1==7+DE-81#1@B55,RGE
MU%(5GS:Z1LK%)P8<<)NI5^#+51;RY*CU<JF1Q5"=MMO[%2^,.W??RCP=PU./
M*6[&OUO:9[.P9G`/3>_F?7<S1-?7+$E-81#1@EE-K?_LF2I[/UNUW0H^U%"?
ME')-'KB(8<T4)@[5:;MA8HW"6!,]/UYO=QY_N@C./JO4GO3,.]=P=(G^W>*M
M<7X$5$B\7EW<@=Y%/``()=$T@K".F:^^Z<SE;D62U@P5-;1:](/*45[A3V5C
MRBMD?$VASV),H5_:M7.Y8A9GRE.I,$_K\Q$LU@L3'[G42/:VU'.T'-_F7<<:
MS*'!)39[NO==87TS%^M=S1*KD%7G=W<KM6<D+#G9U/6*O9P[QD0;P9NC<'C0
M-)U5;&%E84WW4]ZWK->A-85DK25"$UGEC)906.',UX3+J?K;LDWY%V<+'*=2
MWN*=M(=Q3X\J?@06!':#TT6*YD:RWC18U!QO#NZ[H>-EZ%/Z)6XA-25L0(XS
MK#7-=]VFUG]6?M<=-QJA.[[6:%:OTGK'"_.^OFLU.*+,<>41]N@DFA]R0Q7O
MO)?MQ]/Z]+*]K!_!XDOI.UH(/<OB[/,HSH>)0SFN;CE^DH8N/6SV[FI<=M.[
M>?XT9JE&*ZV;K[6!)=D,+6N!&LRO<H(O]$*=?)XC3'Q__;(NV^OVXTOIP*YX
MZ'ESZGN?H2`<M+QO"3^%E6&B<*7:".;K\KJTLS[303:#9L60+\,8IYR`J^`P
M>9OB%7&$B;O]FL4:P2(*4I]]OO=UBNXYT-3K%/5G41??J=+0DC,YGA'-*_4B
MSL;ONH1+2X6K!5(;_%C''!NS2E7UBTO*0BY;1D;ZJ@D?E!L_VF+"GC+.01H"
M>:^LETOQ?#?Q<O:E^09I5;!21V2&B>:2/5CDP8IC>M\.*FR-VSTCRGL8ZH<O
MC4!]`73QNKR<3\1$L#B@I_69ZQ0!!!T/E"%,!%`;IZ''1*2(9`0-]VD$[OP`
MT!+!XH"(%`$`P"CV8)%X<1Q$B@``8""/8)'!Q7$0*0(`@.$0+`Z"2!$``(R(
M8'$$1(H``&!0!(O=$2D"9S6>ZB.4'3..`)@2P6)?*9'B>O=I_:Q)9H]'S0DK
MNQ-+Z->7TU\"DT%%RS`"3<&2&O9\E4/?5W8%*[5;R^Q:.E.%":H//6M773^K
ME,M2ISMMDTM>82HU;+;7]PFCK87N$M2@CA37]ZE<;OQ4M?WAP^:<2\>CYD+3
M=UKO6BG(Z\OI+[HP44ZA>TL*!1.6IS9[=I'.-%J]6?A:9@>,QKNK;H9*N=3H
M3MOD,E3#GK1/$GW\:4TAC7IT\SZOMXX1EQ)3F16?Y2(Z)V^]?=N;BS"!J3M%
MM::M:G249I&.7*)S-$>3\OX96AYJ)6$=JV5"+:;Y%I3?75)-K>:*9BVO8)4A
M:6,;Y'B&>MI\Q=Y9XR]:ERL6)N1I?7YY'UG<'GO\LAUAXKZ\=^EFIHL4%^.\
M\P4VIRJL@Y,\>[H\]7O+?;+2$=0:6S4CF&@$)A>LWL1Q;LK9>;D?M*JO7,U:
M.?KQJ.CWHEPG5%,A03-:]6X`T2TD.F*JJ11NPMUWE@J;@;O]5\U%/JRTT:9A
MLSV"PNTM'MDVKCII2!TI'MO)7<<7LX^OH2.TE7BEK=XZBK<D]SA65&$MM)K:
M^JR52_:[7=JD<8[CE"ITM<"P!<:PS"TG]$NF;"YF7O5R.?E#L6QAZC7L&2_;
MC]4WIMB[7)/CWN=1#'4Y2*GJ')="R[4SW[5>)WTV]=W&S"N!>I?EDP97([EU
MM[:0T0J,8;6)6F;*Y8J%\=I//>\!HGG-(J>>:R-2+"GUF)<ZRI)ZET;O]HB,
M\UU.KY(WN^6YR-T\24);N[(`U]V6D,=[`F>:7#IJ4^63K%M8K!M<4(_N[/-V
M]^L4W7.@J=<I*L^BFB,NFO6%"]VJ7O(2K5WJ19S97T21=X7K2KV]N;(*FW,7
MH7P3TLG&T7PO)YM47[QHW4-%C=9:V+G&.>ZB'NLFITH=W4RY7+$P7NZ=SMS[
MW$;Z=8IWY3V("DM&6[]Q:T3#B(PLSJ<L-."9]G=?>Z_UD=.4PS4Y<6NYD*.W
MV$E;6NA/X45&@WL34188$]-LY.1R]<)@-.I($4`%H_UJ!P#`1*2(9,0T!=&8
M`("1<4<+````_(@4`0``X$>D"````#\B10```/@1*0(``,"/2!&85G26A6:S
MOP``+DH7*:Z?_]V5-4?M^D%8V9V7HNKZRW6.\4(Y,QI6^:ZR8-XO0KG^^EFI
M4A4W<8QX\MOO77Q$:/:XXKF8R^O59>G:5[1IV#/<N?N8S:\-]6Q^AR$VF`ZL
M6=VL:?3<&3/==X59/HNLOUSG."<'7JD-JWQ763#O%Y&T?O%2U9`W!0[0EV:/
MJY3+4B%,M'+IV%>T:=B3]HF>CQG\K&F@44_BD[?7FT[K=WZG34U!7C\T$[0[
MNVZEUG!+$IHW>0G,O=8^J%46VR64-GNKB#:7^^=Q(#'?LN8[#E5'CJJ]R_4E
MU+=GM([*>BG+YE994V"FD!Y9F^^E30<[U#8V5&%$Z]/Z5E8K3'Q:GU^V'[W+
M-BWF:-&RCBCR[.G>=PNN;ZX0'8"L(?I3>)S!LZ1BYR6K#-?,]>7FBHXQ6TO<
M,8#S5=.T55)[:NKHK9>;5'1CBXZ8:BJ%D7F'^NH-+E;MT(;J+=LT[!G;HUR/
M$EWF%-H,4B+%NPXH[K(/BO)1/&]]LTCN(-`@_8Z^Q^GU[K*4Z6S,+R(4#*7F
MZZZ@^4Z]EU4U/H?5)9?L:G*TN2+W5Y.[O&PN2[4.UJI+WPVR3<.>+>0>)BZ;
M-:;8NUPS8TQQ$J-="6>=!)2+U.M=S0I5VZ=LP4*A><M-HD%&;C6%,\XC%!AE
MM=F>K5PJ=;#R>'GM.D8+,Z3W`'&UKUGDU'-5ZJ?DW'M`42EUW\Y>_RH#(5?H
M=WY*:E+ABRB^#9S_KLV!BE!JQ;>H]MOJR6'CJ^Q3-^<](=,@ES9U:5P`.<<!
M]PCKVL0]6.Q=J%M@3%'%O8XP]3K%VNLW%BVMYJ2PMS<\4_%HLT2++5PPJBQM
MD25YWZ]\YTW&/571ECGS[>CK*'Q0+JIFX#;[L^C%NC.I4F?HO?^I=EV6W*'Q
M&H7I?I1QN7<Z<^]S&^_;085M8&,$<EX7.4DQ2;$!8$RO2X=`[<OZ_,JYYH:>
MUF?F:`$``(`?D2*2771D[J+%!@"@(R)%````^!$I`@``P(]($0```'Y$B@``
M`/`C4@0``(`?D2(``+@`'J;81<IL?NO/!W7?T_HA:8F;B+NR^1$AA=3US16$
M%`#@0D(]6-D^+:-[+U677OUSZ.`RSO'"G;N/V?S:T$6*^Z3/^[\A-IC6]ND]
MS`F.-$O<1,P_-T,H%XOU$4V.9OK>3`'@*D*=7O$`+K5[+U47M]-NPUN8T8X7
M+]O+:DS_9DT#C7HX^ZQ29#]I/!D\D]<!F$QH/O>R?9UWUO(&=>G8:5_B8/%E
M?=Z6=1]')$QLZ1?56N90X@4VIXJ$/?G\?.K1%*QW4]?W+@&`RSFZXJK1E97X
MWG\6S\[,I7L7/51AO+;W,KX')5RPV`AGGQ/(75+>Z0EKMQ12,$\$*$^(6.^Z
M*9QOD.,2EI%?`YB)&\`=>WV]7):/+K1J+L7/<6<7IOCQHE@AE^U]-'&@X'5Z
MG'W6XF2NR[R$9>37`*81"JV6HD-?;3K\H0XK0Q7&ZW7[\0@3M_?QJD>PR.TL
MS1`IJF3O0O)/,4VRYI7.)W,<ZG<A`*3J%<#5Z#R'BLS:5/DDZ]I$@L5FWC<%
MS;::>)WB-M?(L'O;\J*["E"^YD/8.?4IG%P?`*["VQ4?;Y7JUI0=_B5RJ5J8
MUZ7//24\5;&EI_59=T?+<O=+`KS[B>;^..LL2>,4VMS!!P!M"#U8P<Y-V>%?
M(I<K%@:CX>PS````_(@4`0#`9;QN/[ZLS[U+<2-$B@```/`C4@0``%?"L&)+
M1(H```#P(U($```7P[!B,T2*````\"-2!&IQ)SD8<-H#```$ZDAQ_?AW8\<\
M],?K0VA](07-^M;":';1$LHI%&\K(3OW+>_*T4;.+H";N)NUT*JU&S!:N[X%
M`'I1=AW%<SF6UZA1U;H,6.54[JQ]^Q).0+>AFZ-E->9H66\Z7XL[+;WYEG=]
M.87H^HO3@\C3`+KO:M:I1ZZL51)OV4X64OZL,G&S;(T;$(!%V744S^5X7:-&
MT7P;:%GE#/L4S\>DS]8$T*A-/9O?O0D[;>BMO0O3I.!=?S'ZP6,%^>,M6\/-
M-VFZ4LTZFH[2RM0]<IQ)/*/8;LMXFR4:]&N:=U]"M(I;:;/!>W.Q.N0B:J0Y
M>)6S[<'B/EAEA8G[L&+5F:"?UN>7&\\T3:2H=7[B]J04,F)3]]UZD\TK1P2C
MN9<:-0P-^Z567]DG>HLM9VV^>[28\#,CVKS$B+@S<T>HU]&5.K\A)SZ4JE4^
MZ3U8?!1I?3+ZZ:.(3YR&KD87*6YWOT)Q"1SRD_:EU$^9U\8I/VN%(][EC9MK
M"0^.IK:#-S@+Y9M7_>A%!:4:4SGV&2T,<$/"J=*"'9V5FK=#/I^%F6;W`;P&
M53[#/Z;X$2!6'?.[>1BJOJ-E^_B')K8/BSJT&F1GUM0HJ;3FI]SZAMZMI%<C
M;X;VN0/C:+,/NA>FNQWR2=XT.^[F#:I\QGYMXB,<_#@-_=-^TKGJJ>>E<A@Z
MOL2GY-SU=A8O^0HS90IGLEO$WWS=?YNFUL42^GFM/T$L+,S[[2Y_!1E)65>R
M9M<+N(DN8>*LU1RJRC+K%A8K6$1MZNL4]\/3N!M271F7PAS/6%%>3&.M+Z09
M2L1ZU\VQX`4]T925]15*N\3B.?V[FEN.A*M"S>]%^(BW//(=+<IST$+SCMRY
M`S5HNH[BN32N7:\QQ2Y5UG#O=.;>YY;4D>)8FTT'[IXC+SF_OK5<OO5!?C>:
M2^W6T+R5404W5DLJDN;/Z'?D72'4W0MI>K]*X?L=K2L'&M!W'<5SJ937HCL0
MU-:XRK@6[GT&BJEW#R8``%T0*2(985`(+0,`F`SS/@,``,"/2!$```!^1(H`
M``#P(U($``"`'Y$B````_(@4`0``X*>(%%?GS]59>`/K!V')L5#X^+&"NR24
MKYQC:.50>9@.#L!U*;OBXKD<RVO4J&I=\JJL/$*UY,[@QYQ^;<0B13=,W#[^
M#;'E-+)/N6;.'.4N,1=Z$]D,[I^A?(4R""N'RC/(#@\`&91=<?%<CN4U:A3-
MMP%OUIJ#5$O6=,_69-"H)Q8I#K%Y]*?93[)G6`]]T%JNF1TXFNP@.SP`9&C3
M@VDZY")2._G&51[2N@>+1YCX97T^_G_24XE$IL0<+6GDSD*>S"UIJC<A?%2F
MD)HC`%S%T4-:8V"5<FD0)IK+:]0EHU2C'D$>P>+V_O_WLGTL)<ZKAT@Q0;2S
M,'<P:TWK%+"PIKF:NTY2MZ7)Y62#'!F-_+IXQ0%T%.I"RW9T5FK>#OE\%FZ:
M]6+3I"J'CED#V-Y/0V\_3SU_!(@OVX^3Z1)KAA`I:C7>56H'>64+.?AK`--H
MTR6&S@L7S'VT3GZ08L3\#!#W:Q8?_W\]'2`>SL>:L^(I.2IGKD&T7LC))MW7
MO'"'"H`[Z1(FMJQ=^TQ#51[PX&+=PF+=X()Z8F.*Z\?_]TW(O.5Y_-\>19F[
MC7N#V!([XWG^?&@T!?-.P-#ZUCH`<"W1KKA&+FVJUO>RF38->X9[IS/W/K<1
MBQ0WQ9(;\.XGFCN+Y?.A95/(2Q\`KD+9%=?(I5)>RQB7S;1I6%P49Y\!``#@
M]S:FN"T5'O+)3Q$``("+>QM3'/#"50````````"#>AM-_/U?_^A=#````(SE
MZ[?OW-$"````/R)%````^!$I8FA?OWU__.M="@``;HIYGY'`#=JZ7.2J*<:^
M#M?@`M.P=OQC[PXM+YN+M4*IOL5*K6Q=3E9YD`X?W7%'"Q)X.[6JVX^0!;$@
M<!^/_=W<V8_=OVRG%,K%6G(F"RL[,[5H[BT;MED!,+C'9L"8(HKQ_C`-]>/6
MBT7\(:O/?4_035_(B'X0&%^;_53.Q>Q;SG-3Z](7T0$BBNL44<81=>W_%EW`
MM_>5YOIN.AG%T&0$`'K6V-M0J=6N.->+WQQCBDA6\$=P\;XRE*!W^55Z:@`F
M\VS`/BQ78V3..@_;+$SL.,IHG6:QSDI?*+I%642*2.9>&P0`;<@7)I8*:(0K
M%(\_S^0BI%:\+ME5!G9$BLAQ_(ZG6P'03+.;/*Q<RMYHTOZVE8PJ`P>N4T2F
MC&O^4J]TJ7UE#!??`!?2*TQL7,%>^5I5IF_$@3%%Y#-'%D-7"YG+-;<-IJZO
MU/T&0P!G'+NPM2^7O4XQE$N;.KH]7H.LY89M7!B,B><I8G*<50$`(,_C&,K9
M9P```/AQ]AF38S01````````````:(([6@```.`QR1TM//8)``"T-W($4JIL
M?][1<J0HS)*TB`_GM!Z_Y!VJW)^]Y^;EKA/*M-[\FSQ.!0"`>Y(CDS/)%H\K
M0D6M-'':GY&B&3#MP9PY,[J0O7?*(V\DZPU&A=!3?O<\;U[,4`<`P*U8PT9%
MI@X_II\H7EIO4>N-;E8Y^^QM9673R^N$WK6>T6_^N;_VMB`1(0``-V?%)^9<
MM<?_A:`B%&.X*;BI+87FE0V%6')T))33_-0ORLR6\,E9S4G;T.A@-%93KN8=
M_K0B>@8+`0!`B'7F,Q1%*&,,[Y^A$[;6Q]W841B`BY[UE?.R$G3?_<6;:S0_
MM^B:$IAK*J,W@CP``-"`.9JXQ"ZH*R7OG&<HLCP3+QV!KY7(ISM:DE)7KF_&
MA4LLDLVK&P``0![Y9@QS(*Q2[MY,A=6B8W9E&\0>4SQ6.NY0-F/,)7SO<]+@
MGW"'T7&FW"V#]:Y<PR5VUW8T+P``<`?6PUODMS31@AQ]>A/W!G\A&7=JA^*Z
M4,J'^9^\S6@E```HXFY!Q21/W@8``$`-OYQ/XA%OOFP_>E<D:.2R`0"`"YDX
MJ/B_W_[7NYPQ10```/@%(T7AL9!%GA()``"`P?DC17>:N^,>&>M/````S,H?
M*=[JOAX```!X<9TB````_(@4`0``X$>D"````#__\Q2%:>Z8]0X``.`F_)&B
M%07*?P(``&!*!>9H.1Q/]_ZWO_T[2UC"$I:PA"4L80E+KK(D9%U.CQ$./IL?
M````9-[9_!XQ'G>T````P(]($0```'Y5KE-<WD][6W_VKBD```#2E(P4,RZ3
M!```P+#2SC[O3U+<7QRO+8\P40X0'ROL_X[7[G(```!TEW.=XOY$;LV:H<CO
M$4KNIZ>/%^;RWFT"``"`-\F1HAPFF@.*>]AG7;`HT*\)``"`!M*N4S1CQ!HS
MM1P#C;V;!0```.EWM)B7)UK!HA7DI=[7PH`B``#`4-(B1?G4LQ41A@)$\_2T
M^8*A1```@*'PY&T```#X)5^G*)Q]!@``P$Q*GGT&``#`3#C[#````+^2]SX#
M``!@)OG/4P0``,#<./L,````/R)%````^!$I`@``P(]($0``X+Z>UF?A72)%
M````^!$I`@``W)HPK)@3*7[]]MU\JB(```"FE!PI[A/Z61-``P``8#Z<?08`
M`(`?D2(```#\B!0!``#@1Z0(````OU]2/W#<R_)XT;OP````J"@Y4ER($0$`
M`.Z!L\\```#PRQE3=)^D*,\8"```@)&%KBTL</9Y?Q9WI4+/=*9[LNI0H_%-
M5AUJ-+[)JD.-QC=9=;K7R#NIREAGG[_^_?OC7W1Y:+41:,IYH>J8-=K+.4&-
MK'+.5*.CM--49[XO:((:T<N-7R.KG#/5Z"CM--49_PO*&5.LY-$$O__'/\P7
MWN6AU49@?:E7KXY5HZ-XEZZ1:;X:+8$.]*+5"95P@AI==Y.CEQN_1J;Y:K30
MRS6OT5ACBAF$'TSMG?_^AJI.D1HME_IM=_4:Y74BPU;G3#M0HTKFZQ/FZ[?/
M&[E&&;W<R-7);H26-1IH3'&/FA=SO_U5^\'E"C\=YJC.IX)1HY%JY"G/E:MS
M5&J9J$^@E[M$=:;I$^:K$;U<EQH5B!1+77KI#JX.^(V>,4%UK(U26:.1?\E-
M5B/S<JM'7:Y>G<7I#:]>H^Q>;M@:62:H3EZ?,++):I37RXULJ,C'&]$-??9Y
MY-[DAM5Q?[MH:C3RSCQ9C?92F7W-I:L3*BTU&MG5JY/7)XQLLAKE]7+7,F"-
MUF6D.5>L,5CS][>U?'&VDA'Z':LP5Z^.51[WNF]-C0:LE%N[:6IT%&^:ZF3L
M1-2H0?F7$[W<4-592O1R0U4G5+MI:G24=IKJ#!XJ?/WV?:Q(,:<.0UYV0'4`
MX";FZ[<GJ]%DU6E<HT>D./399P```'3T-J:X;5OO8@```&`LZ[J^W?O\QV__
M[%T2````#(>SSP```/`C4@0``(`?D2)P;5^_?1?^[%B2,:46<JA*[84I6R0S
MM:$JJRSS(`8L$E`*D2*F\NBO]W^]"U*@(FURL5I,GZ_[64U=\NIEY=7W^Y5K
M[;Z;NKZ0;^B)9D1[W=OA\=5<I>6!5`/-^PR<M_?7EWY$:&-'6^WMEM1TUF<K
ME7"H+]0LC%LP]]W4]7O7KYU;51:X-")%3.OXB7_\W#>/RL=;UI)CH;N.FW)H
M97<%[SIF)!$JDOQNM.)+8CARE$HH_Q([S&OJ$FHW9:PO)R(7/NGKL,@%2XU^
MO.M[-SRK390M'&H*^77H1>IR;Z7<!I>_K-`Z2>T0_;KE#2/TI]6K\#,5LR)2
MQ,Q"!S!YX&<1HROERIJQ)7-A-`6YP&ZM%T5<&&TZ98XFN3666,CBEMF,%=SF
MTC2=M_":""E462M$2'I77E_YE2E;>"FT,101*DG>E[54V-*6V,YN9B&G`\R$
M2!%WI+PLK':"WE&B\X5Q<]&/H"0Y\UE-F[@+Y2K4R-I+#A%2`XC&D8<R\=`V
MD[I\$&>^;N#FB!1Q.\KAL;PK]O+6B1:IWE'M3,KG2W4^!?U@Y_E/->">-D41
M-":0C7N?@8@&@XN5"G,8>;#G?)MT+V?JG>/1]:M^4]%"FEO+F=?Z!FE)_@8!
MN!A3Q%3<"P==[O,LY"7"97/1E97K"&GN]R-;GY4?R7'^I+"FT31K6J4UZ^*M
MEUP=.<&DPLN?$M[5?X_N-Z597][JHEN7U<*+N#$TOO-:N5EZ&]_[V>);FINF
M_H-MVA#H8ET8E@<,2=W]58X-9<MYE5I/)J/9Y8^TC!3STA_\VL<B=00&]]BP
M&5,$WB2-P]48M!O?/6L]C@O%3"==<4N[R5<#`````'_Z?Z*GVX&I"%4O````
)`$E%3D2N0F""
`
end
0
Bill_MI
1/6/2011 12:17:17 AM
Reply: