download.microsoft.com problem

Thu Sep 19 17:12:20 UTC 2002

Don't know the history of this input but MS is in the process of an auto
security update for ALL XP machines worldwide. Might have something to
do with this behavior.

On a side note, it kills ALL E-mail attachments (MS files et al) and
significant web content. Security vulnerability in XP. As I told the MS
agent I talked to, kind of makes Windows useless. :)

http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q265424

Best regards,
_________________________
Alan Rowland

Also an ATT BI customer.

-----Original Message-----
From: owner-nanog at merit.edu [mailto:owner-nanog at merit.edu] On Behalf Of
Mike Lewinski
Sent: Thursday, September 19, 2002 9:21 AM
To: nanog at merit.edu
Subject: FYI: download.microsoft.com problem

We're seeing bad throughput via http from both IP addresses we resolve
for this host (207.46.235.150 and 207.46.235.162). Connections from
three unrelated AS all with T1 or better are giving throughput in tests
with wget around 28-64Kbps). Each has a unqiue path to MS.

One of our clients reports that from his AT&T cable modem, he gets
1.5Mbps+ for the same file at the same time. Perhaps they're caching the
files? (not sure how comfortable I'd be with my provider caching
something important like an OS update). Our outbound path to MS
currently traverses AT&T fwiw.

A test to ftp.microsoft.com when this was first reported to us last
night yielded closer to 750Kbps peak and slowly climbing when it
completed, so this doesn't look like a congestion issue AFAICT.
Traceroutes to MS look quite good, no loss and low latency (all under
100ms) as far as they go.

Tests to other sites from all three AS I checked looked significantly
better by a factor of 20-50; I found no evidence of connectivity issues
anywhere I checked except MS.

Copies of the test results and traceroutes were sent to the listed MS
contacts on jared's noc list. No auto-ack or bounces yet....

I made one last test (using IE instead of wget), and things seem
slightly improved, yielding an initial 800kbps that quickly dropped to
300 dropped steadily to a final 112kbps on a 17MB file. Repeating the
wget test also showed some improvement, but not as much (round robin
makes this tough to accurately guage).

Mike