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.