> 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.
