Subject: Re: [tae] Negotiation BOF charter draft

From: "Dan Wing" <[email-masked]>
Date: Thu, 27 Aug 2009 12:04:08 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bryan Ford
> Sent: Thursday, July 30, 2009 7:53 AM
> To: [email-masked]
> Subject: [tae] Negotiation BOF charter draft
> 
> In followup to our TAE bar-BOF on Tuesday, here is an initial draft  
> for a negotiation BOF charter - please bash on it...

Bryan,

I have been on vacation since IETF and just now digging out of my
pile of email.

Have you requested a BoF slot for Hiroshima?  I believe between
Happy Eyeballs and a DNS-based mechanism that Andrew Yourtchenko
is working on, we can help applications use new transport protocols --
which is the first step towards evolving the Internet to *use* 
all of these fancy new things.  I expect MPTCP will also benefit
from these same techniques, not merely 'new transport protocols'
such as SCTP/DCCP.

I hope to bash your charter later today or tomorrow, but wanted to
drop this note to the list earlier -- and to force myself to get
more involved with TAE, as well.

-d

> ---
> 
> 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
> 	- "An Efficient Cross-Layer Negotiation Protocol"
> 		http://bford.info/pub/net/nego.pdf
> 
> ---
> 
> Comments?
> Bryan
> 
> _______________________________________________
> tae mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tae
>

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 31 Aug 2009 17:52:44 -0700

> tolerable and perhaps unavoidable

  "unavoidable due to middleboxes."

> In the interest of enabling  

Do you want to throw multiple interfaces into that (already long)
list of reasons we may see explosive growth in such probes?

> application-layer protocols

That sounds good.

> 		http://bford.info/pub/net/nego.pdf

Andrew Yourtchenko and I will have a DNS-based negotiation protocol ready for
review 'soon'.

-d