> 1. There are two annoying incompetence of TCP. One is that > TCP does not distinguish packet loss caused by network > transmission error from that caused by network congestion. > The congestion control and avoidance mechanism makes TCP > drop its transmit window upon detecting a packet loss, > thus lowers the transmit rate even if the loss is caused > by physical link transmit error. > This results in an unnecessary reduction in link > bandwidth utilization, especially in the environment of > wireless physical links. The Performance Implications of Link Characteristics (PILC) working group has been exploring this. (http://www.ietf.org/html.charters/pilc-charter.html) See draft-ietf-pilc-error-06.txt and draft-ietf-pilc-link-design-04.txt for a discussion of ways to ameliorate performance issues that don't require an alternative to TCP. Bottom line recommendation: implement forward error correction to improve noisy links, don't require the world to adopt a new TCP.
- Re: An alternative to TCP (part 1) Jun'an Gao
- Re: An alternative to TCP (part 1) Jun'an Gao
- RE: An alternative to TCP (part 1) Jun'an Gao
- RE: An alternative to TCP (part 1) Larry Foore
- Re: An alternative to TCP (part 1) Keith Moore
- Re: An alternative to TCP (part 1) Jon Crowcroft
- Re: An alternative to TCP (part 1) Colin Perkins
- Re: An alternative to TCP (part 1) Jun'an Gao
- Re: An alternative to TCP (part 1) Harald Alvestrand
- Re: An alternative to TCP (part 1) Jun'an Gao
- Re: An alternative to TCP (part 1) aaron
- Re: An alternative to TCP (part 1) Richard Carlson
- Re: An alternative to TCP (part 1) John Stracke
- Re: An alternative to TCP (part 1) Bob Braden
- Re: An alternative to TCP (part 1) Keith Moore
- Re: An alternative to TCP (part 1) Mark Allman
- Re: An alternative to TCP (part 1) Kevin Farley
- Re: An alternative to TCP (part 1) John Stracke
- Re: An alternative to TCP (part 1) Mahadevan Iyer
- Re: An alternative to TCP (part 1) Richard Carlson
- Re: An alternative to TCP (part 1) Jun'an Gao
