(Apologies for cross-posting)
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
