From janardhan.iyengar@fandm.edu Sun Nov 1 08:30:26 2009 Return-Path: X-Original-To: tae@core3.amsl.com Delivered-To: tae@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0D223A6896 for ; Sun, 1 Nov 2009 08:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXV89qr4uXPe for ; Sun, 1 Nov 2009 08:30:25 -0800 (PST) Received: from zimfe1.fandm.edu (zimfe1.fandm.edu [155.68.1.74]) by core3.amsl.com (Postfix) with ESMTP id 4AE0D3A687C for ; Sun, 1 Nov 2009 08:30:25 -0800 (PST) Received: from surutti.fandm.edu (unknown [155.68.120.254]) by zimfe1.fandm.edu (Postfix) with ESMTP id C0478D205FE; Sun, 1 Nov 2009 11:30:43 -0500 (EST) Message-ID: <4AEDB7B3.5050709@fandm.edu> Date: Sun, 01 Nov 2009 11:30:43 -0500 From: Janardhan Iyengar Organization: Franklin & Marshall College User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tae@ietf.org References: <549FD1CD-5433-45E6-83A2-C69345E1D5EC@mpi-sws.org> In-Reply-To: <549FD1CD-5433-45E6-83A2-C69345E1D5EC@mpi-sws.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bryan Ford Subject: [tae] Negotiation Bar-BOF at Hiroshima IETF X-BeenThere: tae@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: janardhan.iyengar@fandm.edu List-Id: Transport Architecture Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 16:30:26 -0000 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 From Xiangsong.Cui@huawei.com Thu Nov 19 18:10:34 2009 Return-Path: X-Original-To: tae@core3.amsl.com Delivered-To: tae@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5C0A3A68A2 for ; Thu, 19 Nov 2009 18:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.279 X-Spam-Level: X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[AWL=0.774, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oe6t4IhMB60g for ; Thu, 19 Nov 2009 18:10:33 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 7264E3A6A2B for ; Thu, 19 Nov 2009 18:10:33 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTD00GJGY18HU@szxga03-in.huawei.com> for tae@ietf.org; Fri, 20 Nov 2009 10:10:20 +0800 (CST) Received: from c00111037 ([10.111.16.88]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KTD00LIOY18XR@szxga03-in.huawei.com> for tae@ietf.org; Fri, 20 Nov 2009 10:10:20 +0800 (CST) Date: Fri, 20 Nov 2009 10:10:19 +0800 From: Xiangsong Cui To: janardhan.iyengar@fandm.edu, tae@ietf.org Message-id: <00f701ca6986$9c69bd30$58106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <549FD1CD-5433-45E6-83A2-C69345E1D5EC@mpi-sws.org> <4AEDB7B3.5050709@fandm.edu> Cc: Bryan Ford Subject: Re: [tae] Negotiation Bar-BOF at Hiroshima IETF X-BeenThere: tae@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Architecture Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 02:10:35 -0000 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" To: Cc: "Bryan Ford" 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 > tae@ietf.org > https://www.ietf.org/mailman/listinfo/tae