[tsv-area] Transport negotiation

[Bryan Ford <[e-mail]>]

Hi Joe,

I wanted to follow up with you on your comment during my TSVAREA  
presentation, about using DNS as a mechanism for negotiation among  
multiple transports an application may support, since we didn't manage  
to hook up in person afterwards in Minneapolis.  (Note that I'm cc'ing  
this to a couple relevant lists.)

As I said during the presentation, philosophically I agree that DNS  
might in theory serve as a reasonable point in the architecture to  
negotiate among multiple transports.  I can see four specific  
practical issues with this approach, however:

1. Such negotiation would only work when DNS is used to resolve a  
target endpoint; transport negotiation would be impossible (or would  
have to use a different mechanism) if the user enters a URL into a web  
browser containing a raw IP address, for example, or a cryptographic  
HIP endpoint, or a name in some other naming system.  In an ideal  
world where all relevant naming systems support transport negotiation  
and users and applications never see or care about IP addresses  
directly, this limitation might not be a problem, but it feels to me  
like we're still a long way from living in that ideal world.

2. Transport negotiation via (at least the current) DNS would  
inherently have to be an operation driven exclusively by the client,  
in which the server is merely a passive participant.  That is, the  
server first passively publishes some DNS information about  
alternative transports it is making available, and to initiate a  
connection, the client looks over this DNS information and decides  
which transport to use: by the time the server gets involved in the  
setup of any particular connection, it is already too late for the  
server to have any say in the decision.  For whatever it may be worth,  
an "online" transport negotiation mechanism like the one I suggested  
would allow both the client and the server to be involved: e.g., the  
client sends a "Meta-SYN" listing the transports it supports in  
preference order, and the server picks the first one it supports - or  
the one the server most prefers, if the server wishes to override the  
client's preference order.  Not to say that any particular negotiation  
mechanism is necessarily the "right" one - these are just examples -  
but allowing for online negotiation seems to provide more flexibility  
for servers than just passively publishing information in DNS records.

3. There may be a robustness or at least "user annoyance" issue with a  
DNS-based solution if it is used to negotiate among "traditional"  
transports that operate directly atop IP.  Suppose the server claims  
via DNS to support both SCTP and TCP.  The client sees this DNS  
information, picks SCTP, and tries to initiate an SCTP connection, but  
it turns out some firewall or NAT in the path doesn't support SCTP so  
the connection gets silently black-holed.  In the worst case, the  
connection fails even though TCP would have succeeded, because the DNS  
information only represents the server's capabilities and not the  
network's.  Alternatively, the client tries each mutually supported  
transport sequentially in preference order, in which the user has to  
wait for SCTP to time out before the client falls back to TCP - a  
slightly better scenario, but still seriously problematic in practice;  
see Stuart Cheshire's presentation in the IETF 72 plenary (http://www.ietf.org/proceedings/08jul/slides/plenaryw-6.pdf 
) for related issues arising from IPv4 versus IPv6 negotiation.  If  
the client takes the "safe" approach of just shotgunning the server  
with parallel connections via all mutually supported transports, we're  
back to the same efficiency troubles we have now even without any DNS- 
based "negotiation" mechanism.

4. We haven't yet talked about precisely _how_ a DNS-based mechanism  
would handle transport negotiation.  As it turns out, the current DNS  
SRV mechanism of RFC 2872 is precisely wrong for this purpose, because  
it embeds the transport name (e.g., '_tcp' or '_udp') in the name to  
be looked up rather than in the information returned from the DNS  
lookup.  So if the client wants to see if the server supports each of  
N alternative transports, it has to make N separate DNS requests.   
Multiply N by 2 for the forseeable future, since in practice most dual- 
stack clients will need to check for both A and AAAA records (again  
see Cheshire's IETF 72 plenary talk).  And this is even before the  
considerations from issue #3 above force the client to try several  
different transport connection requests in parallel.  Granted, this  
issue could be fixed by defining a new (and incompatible) DNS SRV  
record type that includes only the service in the name and a list of  
supported transports in the (single) response, possibly with a  
separate (IP address or host name, port number) tuple for each - but  
then we start worrying about the effective size limitats of DNS  
responses...

None of this is to say that we should necessarily dismiss DNS-based  
transport negotiation; I just wanted to try to analyze some of the  
challenges involved in that approach.  Your further thoughts on this  
issue would of course be very welcome.

Cheers,
Bryan