Subject: [tae] Transport negotiation

From: Bryan Ford <[email-masked]>
Date: Tue, 25 Nov 2008 23:32:41 +0100

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

_______________________________________________
tae mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tae

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Nov 2008 14:43:35 -0800

> this to a couple relevant lists.)
...
> 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. 

Right. The trick is that there is no such thing as HTTP; it's HTTP over
TCP. What you want is "HTTP by any means"; whether the DNS supports this
is less the issue than the fact that IANA doesn't really define such a
thing.

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

I'm confused as to how you expect to proceed here. Whether it's an
amorphous SYN or a DNS request, you still need to be able to express
more than a single packet's worth of info, by definition. You talk about
TCP and SCTP, but in reality it's "TCP that supports the options I
require" that matters. I don't see how to negotiate how to negotiate
without starting off with a negotiation - which is what a TCP SYN, e.g., is.

There are several levels of such negotiation that need to happen - IP
version, TCP vs. SCTP vs. UDP etc., the options of the transport, etc.
How do you expect to bootstrap "what transports can you speak" without
some sort of common protocol?

Joe

---

From: Janardhan Iyengar <[email-masked]>
Date: Wed, 26 Nov 2008 11:24:03 -0500

Hi Joe,

> is less the issue than the fact that IANA doesn't really define such a

You are right in that IANA does not define a HTTP over * (or 80/*). But IANA does not decide which application gets to use which transport, the application does. As a result, an application (SIP, for instance) that supports using any of UDP, TCP or SCTP registers all three with IANA, and has to try one of several hacks to actually establish a connection using a desired transport. 

The idea on the table is to make this negotiation cleaner, so that hacks don't need to be used for current and future transports.

> some sort of common protocol?

Then what we need is a transport negotiation protocol that allows a client to initiate a session with a "multi-transport" SYN (with per-transport options), no? IP negotiation is a different beast, IMHO, than transport negotiation. At the transport, the two ends matter the most, and we need to be able to "get through" the (not-so-transparent) middleboxes. 

There is one more concern with DNS-based solutions that I want to add: A DNS-based solution will not work in networks such as peer-to-peer networks where most peers are identified by their IPs. DNS is not an option for endhosts that do not have DNS entries to begin with. 

I don't think it is reasonable to expect _every_ "multi-transport" communication session to use DNS, since there are many "single-transport" sessions today that don't.

regards,
- jana

-- 
Janardhan Iyengar
Assistant Professor, Computer Science
Franklin & Marshall College
http://www.fandm.edu/jiyengar
_______________________________________________
tae mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tae

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Nov 2008 14:44:49 -0800

Janardhan Iyengar wrote:
> You are right in that IANA does not define a HTTP over * (or 80/*). But
> IANA does not decide which application gets to use which transport, the
> application does. As a result, an application (SIP, for instance) that
> supports using any of UDP, TCP or SCTP registers all three with IANA,
> and has to try one of several hacks to actually establish a connection
> using a desired transport.
> The idea on the table is to make this negotiation cleaner, so that hacks
> don't need to be used for current and future transports.

Agreed.

> Then what we need is a transport negotiation protocol that allows a
> client to initiate a session with a "multi-transport" SYN (with
> per-transport options), no? 

At least.

> IP negotiation is a different beast, IMHO,
> than transport negotiation. At the transport, the two ends matter the
> most, and we need to be able to "get through" the (not-so-transparent)
> middleboxes.

Well, IP is also an E2E protocol that needs to get through. You need to
know whether the other end speaks IPv4 or IPv6 too. You can't just say
it's as simple as the transport protocol.

Then there's also potential negotiation of the application protocol too.

> There is one more concern with DNS-based solutions that I want to add: A
> DNS-based solution will not work in networks such as peer-to-peer
> networks where most peers are identified by their IPs. DNS is not an
> option for endhosts that do not have DNS entries to begin with.

It can be; that's the basis of Bonjour (i.e., assume every host runs its
own DNS server).

> I don't think it is reasonable to expect _every_ "multi-transport"
> communication session to use DNS, since there are many
> "single-transport" sessions today that don't.

They use /etc/services or some other list or hard-coded version of port
numbers. That was also the case with hosts back in the mid-1980's; isn't
it time for something a little more automated?

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Nov 2008 16:24:13 -0800

Lloyd Wood wrote:
...
> On choosing transport, couldn't http:// just map to
> http/<whatever-is-favoured>:// ?

we say:
	service://location/directory...

service is an application protocol
location is either a DNS name or an IP address, where the latter makes
the network protocol explicit (IPv4 or IPv6).

We could exploit the DNS SRV format here:

	service://_transport.location/directory...

> Explicitly asking for http/tcp:// or http/sctp:// would produce
> different behaviour. I don't see a need to involve DNS here -
> but I'd quite like to be able to specify http/tcp/ipv6:// or
> http/sctp/ipv4:// to force behaviour in the browser, while
> knowing that http:// just works.

http:// doesn't "just work" - it specifically indicates "HTTP over TCP"
IMO. And http://10.0.0.1/ specifies "HTTP over TCP over IPv4".

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 27 Nov 2008 00:04:45 +0000

> is less the issue than the fact that IANA doesn't really define such a

Worth mentioning a couple of drafts contemplating HTTP running over
something other than TCP:
Preethi Natarajan's HTTP over SCTP, with modifications to Apache,  
which got talked about in Minneapolis:
http://tools.ietf.org/html/draft-natarajan-http-over-sctp

Our proposal to use HTTP for peer-to-peer rather than client-server
transfers, and to layer it over whatever transport is suitable for
the local environment:

http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery
(presented at IETF 71 in Philadelphia.)

I'd be interested in knowing of other, similar, work and seeing
what commonalities there are.

On choosing transport, couldn't http:// just map to http/<whatever-is- 
favoured>:// ?

L.

introducing the world's surfers to layering is just a bonus.

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 27 Nov 2008 01:01:20 +0000

We'd be specifying the "service" more accurately with mechanism/ 
transport. (actually,
/ is reserved for uris according to RFC2396 and using it would open a  
can of syntactic worms, so let's use mechanism-transport as dash is  
fine. I see Preethi skipped delimiters with her "httpsctp"; https- vs  
http- follows the usual security naming, at least.)

If the transport is unspecified, it would go to the default of http- 
tcp-ipv4: - so http://10.0.0.1/ would work as expected by being  
equivalent to http-tcp-ipv4://10.0.0.1/ , while http-tcp- 
ipv6://10.0.0.1/ generates an error.

And yes, http-tcp would be the usual expected mapping for this  
superset of the "http:" defined in RFC2616, that currently floats  
between v4 and v6 depending on local setup. Configuring away from that  
would be as unusual as turning off v4 entirely.

On 27 Nov 2008, at 00:24, Joe Touch wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Lloyd Wood wrote:
> ...
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkkt6K0ACgkQE5f5cImnZrttagCeO5x9o2c6OivbkXzC8HeqALQr
> otkAoOiKjbG5WBGwra/LCGF62zNfdA+6
> =VruI
> -----END PGP SIGNATURE-----

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 27 Nov 2008 11:22:15 +0100

On 27 nov 2008, at 1:04, Lloyd Wood wrote:

> On choosing transport, couldn't http:// just map to http/<whatever- 
> is-favoured>:// ?

No.

> knowing that http:// just works.

The problem is that the HTML page with these links doesn't know if  
it's going to be parsed on a system with IPv6 or IPv4 connectivity,  
and/or with or without SCTP capability that isn't firewalled. For the  
former, you can use the DNS and the presence of addresses / a default  
route, but for the latter you never really know until you try.