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
On Mon, 18 Nov 2002 14:46:51 -0500 (EST), Mike (meuon) Harrison wrote:
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 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
On Mon, 18 Nov 2002, Jere Retzer wrote:
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
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
participants (5)
-
David Schwartz
-
Jere Retzer
-
Mike (meuon) Harrison
-
Petri Helenius
-
Vadim Antonov