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(_at_)stewart(_dot_)chicago(_dot_)il(_dot_)us or rrs(_at_)cisco(_dot_)com
815-342-5222 (cell) 815-477-2127 (work)