Re: [tae] Transport negotiation

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.

> 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? 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
tae@ietf.org
https://www.ietf.org/mailman/listinfo/tae