I think it would be very difficult to replace TCP. However, a new
That's true. But I don't think it's harder than replacing IPv4 with IPv6.
transport protocol that worked better than TCP in very high bandwidth /
low delay conditions might be very attractive for hosts and applications
that were able to take advantage of it.
I agree. And I believe the relatively high bit error rate and thus the high
packet loss rate in the mobile environment should also be taken into account,
maybe with a higher priority(for commercial reason:-))
I don't agree that abundant IPv6 addresses remove the need for something
akin to a port number. They might remove the need for transport-level
multiplexing, but only if any host could allocate a sufficiently large
subnet, and it's not clear that this will be the case. However port
numbers are also used to form names of connection endpoints, and we have
some need for well-known endpoint names to reach standard services.
I'm sorry I have not make my opinion clear in the key point 3. By saying 'The
services could be registered appropriately' is far from enough.
Knowing well of end point names does not necessarily require a port number. If
there's a DNS extension (well, the DNS 'WKS' record can be extended) that
support a client end query the DNS server for the IPv6 address of the
application service, giving the domain name AND the service name.
Here I consider the (service) end point name consists of the domain name of the
site which provided the service and the service name, formerly the service port
name which is mapped to port number by function call such as 'getprotobyname'.
Or the port number is directly written down in the source code if it is
'well-known'.
ATP counts on the DNS or some other widely deployed directory service to work.
I assume the DNS is a directory service. The assumption itself is a problem but
nevertheless ATP cannot work without a directory service.
For example,.we could make the endpoint name a parameter of a SYN packet,
and have the response include the actual address to be used. This would
be a useful facility for other reasons, including ability to load
balance a service across several hosts without having to result to
NAT-like kludges.
IPv6 anycast is supposed to have the same feature. Now we have another choice.
I think both of them are interesting.