Re: [tae] New draft: announcing the supported transports via DNS

[Caitlin Bestler <[e-mail]>]

On Sep 17, 2009, at 3:57 PM, Andrew Yourtchenko wrote:

> Hello all,
>
> following the discussions at IETF75 on http://tools.ietf.org/html/draft-wing-http-new-tech-00 
> , we have posted the an initial version of a "companion" draft that  
> we think should help addressing some of the concerns:
>
> http://www.ietf.org/id/draft-yourtchenko-tran-announce-dns-00.txt
>
> Abstract:
> While TCP has enjoyed many enhancements over the decades, it is
> useful to allow applications to use transports beyond just UDP and
> TCP and to use TCP in new ways.  It is inefficient to naively probe
> the server using the new protocol.  This document proposes a new DNS
> resource record which provides an efficient way to query which
> protocols are supported by a server.
>
> The comments are very much welcome.
>

This looks like a solid starting point for a DNS-based solution.

The main problem I see is that the comma separated mechanism is  
probably insufficient to deal with the combination of
encryption protocols, transport protocols and special adaptations  
(RDMA, SCTP Partial Reliability, etc.) Something more
along the lines of a unique Java class name might be needed, with  
simple reserved names for the obvious: tcp, udp, sctp, ...

But more fundamentally I think there needs to be a discussion on the  
merits of various fundamental approaches. There
are at least three that I can think of:

* Extending a service discovery protocol, such as SLP.
* Extending DNS.
* One step protocol negotiation, presumably by identifying a new TCP  
option.


Some observations on using a Service Directory vs. DNS

It is indeed a service that is being looked up. Just because a host  
has SCTP does not meet that ULP X running
on that host knows how to use SCTP. Therefore these  entries are  
service specific. This can lead to an explosion
in DNS entries, especially if you have a multi-homed SCTP server that  
offers many traditional mini-serivces (echo,
time, etc.). If the DNS approach is used, allowing some form of  
wildcarding may be useful.

On the other hand, application developers seem to be hopelessly  
addicted to DNS.

The DNS approach will be challenged to deal with a service that is  
provided by a cluster of servers, especially
if some of the transports are only available on a portion of the  
servers.



The problem with any directory based solution is that it only works  
for registered services with names.
It does not encompass services that are advertised by other means  
where the application obtains the
IP address of the server by application specific means.

A one step protocol negotiation works for any client/server pair, and  
adds at most one extra step to
connection/association setup. It would work as follows:

1) client sends a lowest-common-denominator TCP-SYN with an option  
indicating the desire to
     use a set of alternate enhanced transports.
2a) If the server does not understand the option, it is not include in  
the SYN-ACK and a generic
        TCP connection is established.
2b) If the enhanced transport is still a TCP connection, the server  
responds with an option indicating
        the enchancements accepted.
2c) If the alternate transport selected is not TCP,  and the client  
indicated that it could receive requests
        on the alternate protocol, the server will initiate the  
alternate transport connection/association.
2d) If the alternate transport selected is not TCP, but the client  
must initiate, the TCP SYN ACK indicates
        where the connection/association should be established.


















                      344344e\\\
\\]]0000000000000