Vadim Antonov wrote:
People are doing various kinds of video over Internet 1; works fine.<<<
Then I must be doing it all wrong because I’ve never had much luck. Maybe it is a function of the origin and destination location + network. Since Portland is not a top 25 market our service has never been very good — that’s why we started an exchange
Jere Retzer wrote:
Vadim Antonov wrote:
>>>People are doing various kinds of video over Internet 1; works fine.<<<Then I must be doing it all wrong because I've never had much luck. Maybe it is a function of the origin and destination location + network. Since Portland is not a top 25 market our service has never been very good -- that's why we started an exchange
The unfortunate development in the video market has been high deployment of
two applications which do "streaming" without too much regard to how the underlying
network works. One sends a high number of fragmented packets and the other is highly
suspectible to retransmission collapse where retransmission requests and
retransmissions actually overload the already congested path by a margin.
Additionally, the deployment habit of content providers to prefer HTTP instead
of RTP/UDP makes monitoring and improving on these services and their performance
quite challenging.
Pete
I am testing a Cogent 100mbps connection with a simple
web based speed test check..
Can I beg those of you on real high bandwidth connections
various places on the 'net to run the speed test check on:
http://speedy.higherbandwidth.net
It logs your IP and speed.. I am trying to determine how
good this connection is. During the day it seems awfully slow
from a lot of places that I have access to.
It also appears to block Gnutella and similar protocols.
Any comments regarding using Cogent as an upstream
would be appreciated (in private?). This is a 'freebie'
for a few more days...
Mike Harrison
Real job: mike@highertech.net 423-266-6536
Helping test a city sponsored metronet: www.metronetchattanooga.com
You should never sign an IP access agreement that doesn't give you access to
the filtering rules that affect your traffic. Ideally, you should strongly
avoid agreements that don't let you opt out of filtering you don't want.
Here's the type of language we typically insist on. If a provider won't
agree to this type of language, odds are very high they plan to filter your
in strange ways or aren't serious about providing business-class IP services.
1) XXXXXX agrees to provide YYYYYYYY with information about any filtering
rules that apply to traffic to or from YYYYYYYY. Such information shall
include a precise description of what types of traffic the filter affects.
2) Where possible, XXXXXX agrees to provide YYYYYYYY with 2 business days
advanced notice to any planned filtering changes. In the event that XXXXXX
makes an emergency or expedited filtering change that affects traffic to or
from YYYYYYYY, XXXXXX agrees to notify YYYYYYYY as soon as practical.
3) In the event XXXXXX makes a filtering change that affects traffic to or
from YYYYYYYY, and such change is not justified by technical necessity or
emergency, XXXXXX agrees to, at YYYYYYYY's request, either remove the filter
or exempt traffic to and from YYYYYYYY's network from the filter.
To qualify as an emergency filter, a filter must be temporary. Technical
necessity includes, but is not limited to, the following types of
filtering:
A) Dropping packets with invalid source addresses. This would include
RFC1918 or unassigned addresses.
B) Dropping packets at the request of the originator or recipient of those
packets.
The following types of filtering are not considered technical necessity:
A) Blocking specific ports or protocols because an exploit or attack might
use them in the absence of knowledge of a specific attack source or
destination. This would including blocking a particular TCP or UDP port in
response to its being used by a trojan or probe.
B) Blocking specific types of packets (by port or protocol) even though they
are technically valid IP packets with valid source and destination addresses
for purposes of disabling particular applications or protocols. This would
include, for example, blocking packets with an IP type of 255 (raw IP).
A dialup account is one thing. But 100Mbps business-class access is another
story. You should know exactly what's happening to *your* traffic.
DS
Yep, Intenet service quality is very uneven; and it does not seem to be an
easily quantifiable factor allowing consumers and businesses to select a
provider. So, all providers looking the same, they choose the
lowest-priced ones, thus forcing providers to go air transport way (i.e.
untimately destructive price wars).
With full understanding of political infeasibility of proposed, I think
that the best thing ISPs could do is to fund some independent company
dedicated to publishing comprehensive regional ISP quality information -
in a format allowing apple-to-apple comparison. Then they could justify
price spread by having facts to back them up.
--vadim
>It also appears to block Gnutella and similar protocols.
You should never sign an IP access agreement that doesn't give you access to
the filtering rules that affect your traffic. Ideally, you should strongly
We have not signed a thing. If I even attempted to explain the complex
political fiasco that got us here, even Nanog members would be shocked.
And as interested parties are on this list (I got a call already)
and monitoring this discussion, I'll refrain.
Theoretically, the other end of this 100mbps connection is
Gig-E and is costing $20-30g/month.. we are testing it for
suitability for our purposes... so far it is not making the grade.
We've been spoiled by a UUnet and AT&T connection. 
For those that wanted the bad (140 lines of perl) speed check CGI,
it's: http://speedy.higherbandwidth.net/speed.zip
No, it's not secure or very bright.. It's a quick idiot check
and is very useful, especially when it can use an suid'd MTR.
And lastly, THANK YOU for all the testing, the marvelous traceroutes
and data collected and the personal (mostly off-list) e-mails regarding
Cogent.
--Mike-- alpha/beta-testing metronetchattanooga.com
Several of the people that ran speed tests asked for
results.
It's not a majorly scientific test, lots of variables
of web browsers and available BW between any two points.
http://speedy.higherbandwidth.net/resultsallip.cgi
(grouped by IP address)
and
http://speedy.higherbandwidth.net/resultsall.cgi
(sorted by speed)
You can now click on an IP address and see the traceroute
and results of other people.
Show that it's a FAST connection in certain directions
some of the time. Lots of burstiness.
Thank you for helping us test this connection.
The jury is still out.. however, this speed test server
will go offline this evening.
Several of the people that ran speed tests asked for
results.It's not a majorly scientific test, lots of variables
of web browsers and available BW between any two points.http://speedy.higherbandwidth.net/resultsallip.cgi
(grouped by IP address)and
http://speedy.higherbandwidth.net/resultsall.cgi
(sorted by speed)You can now click on an IP address and see the traceroute
and results of other people.Show that it's a FAST connection in certain directions
some of the time. Lots of burstiness.
Are you talking about burstiness in time or by ip address ?
If the former, do you have statistics on that ?
Regards
Marshall Eubanks
Are you talking about burstiness in time or by ip address ?
If the former, do you have statistics on that ?
Over time.. It seems to have good moments and bad moments.
I'll be setting up smokeping next for latency testing.
No real data yet.. I'm kinda new to having to do this kind of thing
it's been quite an education.