Re: [tae] Negotiation Bar-BOF at Hiroshima IETF

[Xiangsong Cui <[e-mail]>]

Hello all,

I am interested in this topic but I missed the Bar-BoF session,
would you please introduce some information about the discussion?

Thanks in advance!

Xiangsong

----- Original Message ----- 
From: "Janardhan Iyengar" <[e-mail]>
To: <[e-mail]>
Cc: "Bryan Ford" <[e-mail]>
Sent: Monday, November 02, 2009 12:30 AM
Subject: [tae] Negotiation Bar-BOF at Hiroshima IETF


> 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
> _______________________________________________
> tae mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tae