[tae] Negotiation Bar-BOF at Hiroshima IETF

[Janardhan Iyengar <[e-mail]>]

Dear all,

We have planned a "Negotiation" Bar-BOF session at the Hiroshima IETF, with the goal of identifying  mechanisms for negotiating among multiple protocol possibilities within and across layers. I am re-circulating (see below) a draft Charter that describes the goals of this Bar-BOF in more detail.

Where: Castleview 1
When: Tuesday, 1300-1500  (there is a meeting in there until 1300, so we may start a bit past 1300)

I am planning to have a presentation to lay out some thoughts on the negotiation problem  (I will do this presentation in TSVAREA as well), and open up the floor for discussion as to what the right directions and foci within the IETF should be.

Please let me know if you'd like a slot to present in this Bar-BOF (name, title, duration), and please come over if you have any thoughts or ideas to share.


Draft Charter:

A major challenge the Internet faces in the evolution to and deployment of new protocols is enabling upgraded hosts to detect efficiently whether a would-be communication partner supports the new protocols, and automatically fall back on older protocols if not.  If the upgraded host first attempts to use the new protocol and falls back to the old protocol only after the former attempt fails, the host risks incurring long timeout delays on connection that are highly visible and annoying to users, greatly decreasing the likeliness that users, operating system vendors, or application vendors will adopt the new protocols.  If the upgraded host attempts connections using the new and old protocols simultaneously, the host wastes resources both in the network (redundant initialization packets) and on the end hosts (redundant transport control blocks when multiple connection attempts succeed but only one is needed).

Some inefficiency due to concurrent connection attempts is probably tolerable and perhaps unavoidable in the interest of enabling negotiation without risking long startup delays, but this approach alone will not scale in the long term, for two reasons.  First, the number of alternative protocols among which to negotiate may increase over time.  If an application can run atop TCP, SCTP, or DCCP, then negotiating among them may incur the network and end host costs of three redundant connections, not just two.

Second, negotiation is often needed at multiple layers simultaneously.  At the network layer, to enable deployment of IPv6 without risking poor user experiences, a host needs to be able to try connecting via IPv6 but fall back to IPv4 if necessary without incurring long delays.  At the application layer, applications often need to decide whether to operate with or without TLS, which can be problematic if the original application protocol was not designed to support TLS negotiation and was not assigned a separate port number for its TLS variant, or an application may wish to negotiate efficiently between multiple similar or equivalent application protocols without the user's involvement: e.g., POP3 versus IMAP, SIP versus IAX2.  If a host tries to make negotiation decisions for each layer serially (i.e., first choose IPv4 or IPv6, then TCP versus SCTP versus DCCP, then SIP versus IAX2), then it risks even longer connection delays.  If a host tries to make all such negotiation 
decisions in parallel via simultaneous connection attempts, then the combinations multiply across layers: e.g., with two alternatives at the network layer, two at the transport layer, and two at the application layer, a host will be attempting eight simultaneous connection attempts, an explosion that will quickly become infeasible.

The task of the proposed Negotiation (NEGO) BOF will explore the development and specification of both short-term and longer-term solutions to this negotiation problem.  Short-term work would address specific common cases that are of some immediate urgence, such as negotiating efficiently between the IPv4 and IPv6 versions of a single TCP-based application protocol such as HTTP - a problem that is urgent because of the imminent exhaustion of the IPv4 address space.  Longer-term work would be to develop a negotiation mechanism addressing the scalability problems discussed above.  Technical details such as whether this negotiation mechanism would operate out-of-band (e.g., via DNS) or in-band (directly between the hosts wishing to communicate) will have to be decided within the group.

Tentative work items, vaguely in order from short-term to long-term:
	- Best current practice(?) on negotiating between the IPv4 and IPv6 versions of a single transport and application protocol.
	- Specification of generic, extensible negotiation protocol or framework ("Nego")
	- Spec for using Nego to migrate to new transports with fallback to TCP
	- Spec for using Nego to migrate to new transports with fallback to UDP
	- Spec for using Nego to negotiate use of transport with vs without TLS/DTLS
	- Spec for using Nego to negotiate among application-layer protocols

Reference materials:
	- "Happy Eyeballs: Successful Introduction of New Technology to HTTP"
		http://tools.ietf.org/html/draft-wing-http-new-tech-00
	- "A la carte: Announcing the supported transport protocols via DNS"
		http://www.ietf.org/id/draft-yourtchenko-tran-announce-dns-00
	- "An Efficient Cross-Layer Negotiation Protocol"
		http://bford.info/pub/net/nego.pdf

Thanks,
- jana

-- 
Janardhan Iyengar
Assistant Professor, Computer Science
Franklin & Marshall College
http://www.fandm.edu/jiyengar