best effort has problems
Greetings Nanogers, I published a two month issue last weekend with the bottom line conclusion that there can be no telecom recovery as long as the industry relies solely on the best effort business model which I believe is not economically sustainable. This has led to two articles on my June-July issue conclusions this week in the trade press. Something that has never happened to me before. :-) The first is ISP Planet and the second Broadband Edge. Here are the urls http://www.isp-planet.com/perspectives/2004/cook_internet.html (monday) http://bbedge.mblast.com/presentation/page798-878156.asp (today) Finally my summary, table of contents and list of contributors is at http://cookreport.com/13.04.shtml Enjoy the weekend. -- ============================================================= The COOK Report on Internet Protocol, 431 Greenway Ave, Ewing, NJ 08618 USA 609 882-2572 (PSTN) 703 738-6031 (Vonage) Subscription info & prices at http://cookreport.com/subscriptions.shtml Report on economic black hole of best effort networks at: http://cookreport.com/13.04.shtml E-mail cook@cookreport.com =============================================================
On 28-mei-04, at 21:58, Gordon Cook wrote:
I published a two month issue last weekend with the bottom line conclusion that there can be no telecom recovery as long as the industry relies solely on the best effort business model which I believe is not economically sustainable.
I fail to see how the facts support such a conclusion. What's happening in the fiber business is free market economics 101. Sure, if people would magically start paying much more money in order to be guaranteed what they get anyway today, the people taking that money would be a lot happier. What else is new. Still, such a "better than best effort" service has interesting technical consequences. A "better" service can't exist without a "worse" service. You can delay and drop packets a little with a lower-quality service, but not too much because TCP won't have it, leading to congestion collapse with a network full of retransmissions that never make it to the other end. So what we need is a new transport protocol or modifications to TCP that make it possible to use the available bandwidth even at high levels of congestion.
GC> Date: Fri, 28 May 2004 15:58:06 -0400 GC> From: Gordon Cook GC> I published a two month issue last weekend with the bottom GC> line conclusion that there can be no telecom recovery as GC> long as the industry relies solely on the best effort GC> business model which I believe is not economically GC> sustainable. The PSTN doesn't offer guaranteed end-to-end transmission, and certainly statmuxes based on expected load. Looks like similar capacity planning. Perhaps you refer to latency. Most people don't care as long as HTTP and POP3 latency is "good enough" -- and server response time is often a substantial consideration. SMTP really isn't picky about latency or jitter. Maybe you mean packet loss. Most everyone here can recall the days of 30% packet loss across congested MAE FDDI fabric, but that went away what seems like eons ago. Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses : blacklist@brics.com -or- alfra@intc.net -or- curbjmp@intc.net Sending mail to spambait addresses is a great way to get blocked.
The PSTN doesn't offer guaranteed end-to-end transmission, and certainly statmuxes based on expected load. Looks like similar capacity planning.
The PSTN does guarantee a certain service level, latency, call completion etc.
Perhaps you refer to latency. Most people don't care as long as HTTP and POP3 latency is "good enough" -- and server response time is often a substantial consideration. SMTP really isn't picky about latency or jitter.
Latency & Jitter are very important when dealing with sound & video. Or anything realtime for that matter. The Internet isn't just HTTP, NNTP, SMTP any more.
Maybe you mean packet loss. Most everyone here can recall the days of 30% packet loss across congested MAE FDDI fabric, but that went away what seems like eons ago.
I remember quite a bit of packet loss when the last series of worms hit
MC> Date: Sat, 29 May 2004 14:26:01 -0400 MC> From: Matthew Crocker MC> The PSTN does guarantee a certain service level, latency, MC> call completion etc. As do many Internet providers. (s/call completion/packet loss/) MC> Latency & Jitter are very important when dealing with sound & MC> video. Or anything realtime for that matter. The Internet MC> isn't just HTTP, NNTP, SMTP any more. Nitpicking: Latency isn't that important with unidirectional communication. However, VoIP users seem reasonably happy with current latency and jitter -- and the Internet still is _largely_ xxTP, anyway... particularly if one ignores peer-to-peer file- swapping programs. MC> I remember quite a bit of packet loss when the last series of MC> worms hit As do I, but I consider that an exception, not part of standard operation. Admittedly, that may well be an error on my part, considering the increasing popularity of worms and viruses. The PSTN doesn't have botnets of "pwned" phones making prank calls. (Further note that MAE FDDI congestion was more frequent than the current malware field days.) However, I see this as a problem of securing machines, not one of best effort delivery. Choke trunks are used to prevent radio call-ins from overloading the PSTN. Perhaps throttling bandwidth using a slow-moving exponential decay, over a long averaging period, is a good idea. One could allow short bursts of line-rate traffic. End-user duty cycles are low. This is what facilitates current levels of statmuxing, and why packet loss skyrockets when many systems try to operate at line rate for extended durations. Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses : blacklist@brics.com -or- alfra@intc.net -or- curbjmp@intc.net Sending mail to spambait addresses is a great way to get blocked.
On Sat, 29 May 2004, Edward B. Dreger wrote:
Nitpicking: Latency isn't that important with unidirectional communication. However, VoIP users seem reasonably happy with current latency and jitter -- and the Internet still is _largely_ xxTP, anyway... particularly if one ignores peer-to-peer file- swapping programs.
Latency is fine for VOIP as long as you dont interact with the PSTN network, if you want to interact with PSTN then you need echo cancellation if you have high latency on the IP part. Most VOIP applications can handle 40ms jitter, so that's normally no problem unless your local access is full. Packet loss is normally no problem for VOIP if you use a proper (non-telco developed) codec. VOIP is actually better off with high packet loss and low jitter than the other way around (throwing off the old truth that core equipment should have lots of buffers). -- Mikael Abrahamsson email: swmike@swm.pp.se
participants (5)
-
Edward B. Dreger -
Gordon Cook -
Iljitsch van Beijnum -
Matthew Crocker -
Mikael Abrahamsson