Re: [tae] Transport negotiation

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Janardhan Iyengar wrote:
> Hi Joe,
> 
>> 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.
> 
> 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.

>> 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?
> 
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkt0WEACgkQE5f5cImnZrsCpgCfbMeB70I4rTmJ6z3hv8sL8YWF
XnEAn2k99HHM7NOnbH5Y3CwJv54ZqZ9N
=a+/k
-----END PGP SIGNATURE-----
_______________________________________________
tae mailing list
tae@ietf.org
https://www.ietf.org/mailman/listinfo/tae