North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
RE: download.microsoft.com problem
- From: Al Rowland
- Date: Thu Sep 19 13:14:48 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. :)
Also an ATT BI customer.
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of
Sent: Thursday, September 19, 2002 9:21 AM
Subject: FYI: download.microsoft.com problem
We're seeing bad throughput via http from both IP addresses we resolve
for this host (18.104.22.168 and 22.214.171.124). 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).