Re: An alternative to TCP (part 1)
jag@kw.com.cn (Jun'an Gao) Fri, 09 February 2001 03:20 UTC
Received: by ietf.org (8.9.1a/8.9.1a) id WAA24991 for ietf-outbound.10@ietf.org; Thu, 8 Feb 2001 22:20:02 -0500 (EST)
Received: from china.kw.com.cn ([159.226.25.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24956 for <ietf@ietf.org>; Thu, 8 Feb 2001 22:17:37 -0500 (EST)
Received: by china.kw.com.cn (Postfix, from userid 639) id B71EA39ED7; Fri, 09 Feb 2001 11:21:30 +0800 (CST)
To: ietf@ietf.org
Subject: Re: An alternative to TCP (part 1)
Message-Id: <20010209032130.B71EA39ED7@china.kw.com.cn>
Date: Fri, 09 Feb 2001 11:21:30 +0800
From: jag@kw.com.cn
X-Loop: ietf@ietf.org
> My bottom line thoughts after having scanned thread is > have you looked at SCTP? We have just finished almost > 2 years of work and it solves some if not all of your > issues... Before I posted the long (and maybe annoying~_~) essays about ATP I've reviewed a few of the articles about the enhancement to TCP, and other (reliable or partial-order) transport protocols, namely SCTP, RTP+UDP, RTSP+UDP (although RTSP is not designed as a pure transport layer protocol, and may run over transport protocol such as RDP other than UDP) and XTP. It is said that TP4 is obselete so I haven't reviewed it. I think the enhancements of TCP are effective and quite easy to be implemented in a small set of hosts, but unlikely to be adequately deployed in the wide Internet in a duration shorter than migrating IPv4 to IPv6. So why not make a new transport protocol optimized for IPv6 instead of patching TCP? The migration costs may be on the same level while the benefits may not. I think XTP is low efficient. SCTP is a functional superset of TCP, RTP+UDP and RTSP+UDP in the unicast scenario. Different points of SCTP and ATP are: 1. ECN. (But no way to prevent SCTP to exploit ECN). I think explicit congestion notification is a fundamental enhancement to TCP. It is developed later than SCTP. As far as I perceive SCTP had no chance of taking into account the rationales of backward or forward ECN (and early congestion detection), administion control and traffic shaping when it was firstly designed. Behind adopting ECN in ATP there is an observation: Choose the right entity to do the right thing. ECN is not a pure end2end issue, so does ATP. ATP counts on the routing system to CONTROL congestion and cooperates with the routing system to AVOID congestion. 2. Negative Acknowledgement (and the motivation behind it). There is no send timeout except when sending the connection initiating packet (SYN packet) in ATP. The sender resends a packet only at the explicit request of the receiver. That is, the time-out clock is moved to the receiver side. At first sight it makes no difference. Imagine a welcomed network application service encounts heavy load. A request sent by a client may be dropped because the upper layer application cannot handle it. In this case the client has to abort, considerably slow-down or resend the request. The user won't feel well if to abort or slow down while resending the request is not a good news for the heavy-loaded server, maybe nor a good news for some intermediate routers. Or the request may be acknowledged by the transport layer protocol engine. The acknowledgement may make the transport layer such as TCP engine increase its send window (congest window). Thus the client may increase its transmit rate, which is not a good news for the heavy-loaded server. We may call such a problem 'upper layer application congestion' or 'application layer congestion'. It isn't uncommon for ftp or http servers to limit the number of simultaneoues connected users to avoid the application layer congestion. Yet how much TCP should be condemned for the performance degradation in the heavy load time is itself problematic. Though it is expected that ATP may solve such a problem, I have not make it a motivation of ATP. 3. SCTP intrinsically supports multi-homed site. ATP doesn't. The reason: it is still unclear how to support multi-home in IPv6 environment without trading off routing hierarchy (I think the proposal of Jieyun (Jessica) Yu is a good feasible choice 'IPv6 Multihoming with Route Aggregation', draft-ietf-ipngwg-ipv6multihome-with-aggr-01.txt). I think SCTP is superior in this point. 4. SCTP supports multi-streams in a single connection. I cannot perceive the necessity clearly. 5. The raise of the consideration of consolidating the key features of RSVP, ISAKMP, IPSec and IPComp in the unicast scenario. I have yet no clear idea about how to do the job in ATP.
- RE: An alternative to TCP (part 1) aaron
- An alternative to TCP (part 1) Jun'an Gao
- Re: An alternative to TCP (part 1) Valdis.Kletnieks
- Re: An alternative to TCP (part 1) John Stracke
- Re: An alternative to TCP (part 1) stanislav shalunov
- RE: An alternative to TCP (part 1) Christian Huitema
- RE: An alternative to TCP (part 1) Larry Foore
- RE: An alternative to TCP (part 1) Tony Hain
- Re: An alternative to TCP (part 1) stanislav shalunov
- 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) 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) Colin Perkins
- Re: An alternative to TCP (part 1) Rahmat M. Samik-Ibrahim
- 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) Jon Crowcroft
- 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) Harald Alvestrand
- 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) Mahadevan Iyer
- 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) Jun'an Gao
- Re: An alternative to TCP (part 1) Jun'an Gao
- Re: An alternative to TCP (part 1) joaquin.riverarodriguez
- Re: An alternative to TCP (part 1) Jun'an Gao
- Network Edge definition (Re: An alternative to TC… Harald Alvestrand
- Re: An alternative to TCP (part 1) John Stracke
- RE: An alternative to TCP (part 1) Iliff, Tina
- Re: Network Edge definition (Re: An alternative t… Joe Touch
- Re: An alternative to TCP (part 1) Randall R. Stewart
- RE: An alternative to TCP (part 1) Bernard Aboba
- Re: An alternative to TCP (part 1) tytso
- Re: An alternative to TCP (part 1) Jun'an Gao
- RE: An alternative to TCP (part 1) Bernard Aboba
- Re: Network Edge definition (Re: An alternative t… Marvin Sanchez Garache
- Re: An alternative to TCP (part 1) Randall R. Stewart
- Re: An alternative to TCP (part 1) Randall R. Stewart
- Re: Network Edge definition (Re: An alternative t… Lloyd Wood
- RE: Network Edge definition (Re: An alternative t… Bojan Lekovic
- Not developing protocols (was: Re: An alternative… John Stracke
- Re: An alternative to TCP (part 1) Richard Carlson
- Re: An alternative to TCP (part 1) Jun'an Gao
- Re: Not developing protocols Ofer Inbar
- Re: An alternative to TCP (part 1) Mark Allman
- Re: An alternative to TCP (part 1) Fred Baker
- Re: An alternative to TCP (part 1) James P. Salsman
- Re: Network Edge definition (Re: An alternative t… Michael W. Condry