Re: An alternative to TCP (part 1)
"Randall R. Stewart" <randall@STEWART.CHICAGO.IL.US> Fri, 09 February 2001 13:10 UTC
Received: by ietf.org (8.9.1a/8.9.1a) id IAA15451 for ietf-outbound.10@ietf.org; Fri, 9 Feb 2001 08:10:02 -0500 (EST)
Received: from stewart.chicago.il.us (IDENT:root@dsl-64-128-23-213.telocity.com [64.128.23.213]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14906 for <ietf@ietf.org>; Fri, 9 Feb 2001 07:52:17 -0500 (EST)
Received: from stewart.chicago.il.us (IDENT:randall@stewart.chicago.il.us [10.1.1.1]) by stewart.chicago.il.us (8.9.3/8.8.7) with ESMTP id GAA22411; Fri, 9 Feb 2001 06:52:37 -0600
Sender: randall@STEWART.CHICAGO.IL.US
Message-ID: <3A83E812.6A904672@stewart.chicago.il.us>
Date: Fri, 09 Feb 2001 06:52:34 -0600
From: "Randall R. Stewart" <randall@STEWART.CHICAGO.IL.US>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jun'an Gao <jag@kw.com.cn>
CC: ietf@ietf.org
Subject: Re: An alternative to TCP (part 1)
References: <20010209032130.B71EA39ED7@china.kw.com.cn>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
X-Loop: ietf@ietf.org
Content-Transfer-Encoding: 7bit
Some comments for you to ponder... Jun'an Gao wrote: > > > 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. > Do you really think that yet another transport protocol can be designed built and deployed in the world wide Internet any quicker? Even considering a move to IPv6? It will require a good 2 years or so to get the specification done, then you have bikeoffs (with respects to pillsbury :->) and of course you must rally support so that it gets developed so you have enough bikes to race :) I don't see how you can propose a new protocol and get it out any quicker than you will see SCTP deployed... > I think XTP is low efficient. SCTP is a functional superset of TCP, > RTP+UDP and RTSP+UDP in the unicast scenario. > Yes, SCTP shares a lot in common with TCP but there are some striking differences. > 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. No, the problem was that we could not mandate SCTP to use ECN because ECN was an Experimental RFC. Has such we had to stand on our head to get it in and not have a normative reference. I think you will find that in the BIS we will require an SCTP implementation to have ECN. > > 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. Even at that you can NOT solely rely on ECN since it is NOT fully deployed into the Inter-net. You must keep the packet loss is a signal of congestion. Even if ECN were magically deployed everywhere tommorrow, you still have a problem. What happens when a router gets a BURST of traffic that exceeds its buffers. It MUST DROP packets if it runs out of buffer space. A lost packet needs to be intrepreted as a congestion event. I think there may be other ways of detecting a corrupted packet that may be employed... HACK TCP and similar items.. but there still needs to be more research ... > > 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. We discussed this in sigtran... question? How do you know (from the receiver side) that you are missing a packet? You setup a connection with me. Send me something. I respond. You send somthing else, to make an additional request, one I am unaware you are going to make. How do I know to ask you for a retransmission when that packet is lost? > > 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. Look at head of line blocking. This will explain the item you are missing. A telephone example works best but it can also be applied to HTTP or many other apps. I have a connection carrying control information on 20 phone calls, Setup, teardown, addtional info etc. Now The first packet (a setup on call 1) is lost. But setup for call 2, 3 and 4 (in subsequent packets) are received at the server. The TCP connection will hold these packets awaiting the retransmission of call 1's packet. In SCTP you would use seperate streams for each of the calls (or some subset) and thus call 2,3 and 4 would not be held up. HTTP has a similar problem when downloading jpeg's and other pieces. > > 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. R -- Randall R. Stewart randall@stewart.chicago.il.us or rrs@cisco.com 815-342-5222 (cell) 815-477-2127 (work)
- 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