From gorry@erg.abdn.ac.uk Tue Aug 25 05:27:24 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 170923A680E for ; Tue, 25 Aug 2009 05:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 P7QuAxsuXs+r for ; Tue, 25 Aug 2009 05:27:23 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 139EE3A6E0E for ; Tue, 25 Aug 2009 05:27:22 -0700 (PDT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n7PCRLXR028458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Aug 2009 13:27:22 +0100 (BST) Message-ID: <4A93D8AA.2090508@erg.abdn.ac.uk> Date: Tue, 25 Aug 2009 13:27:22 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bryan Ford References: <8272C647-9E3C-4C15-BCF0-01DB52A90742@mpi-sws.org> In-Reply-To: <8272C647-9E3C-4C15-BCF0-01DB52A90742@mpi-sws.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: tae@ietf.org Subject: Re: [tae] TAE bar-BOF summary X-BeenThere: tae@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Architecture Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 12:27:24 -0000 Bryan, Could you explain in a few words what you understand by "naming neutral transport"? Best wishes, Gorry Bryan Ford wrote: > For those interested in transport architecture evolution topics but > unable to attend our lunch discussion yesterday, here's a brief > summary. I believe approx. 15 people attended. We didn't do any > "official" note-taking/minutes during the meeting; this is just my > perspective based on my memory of the discussion, so please correct me > if I forgot something or got something wrong. > > We essentially discussed two meta-topics and one topic, not in any > strict sequence: > > Meta-topic 1: what transport architecture evolution topics are most > interesting to the most people? In particular, which ones might have > enough critical mass surrounding them to be potentially actionable by > the IETF in the near term? Topics we brought up included layering > model, naming-neutral transport, and negotiation. On the last - > negotiation - there was a clear consensus among those present that this > is not only an interesting topic but might have enough definition and > criticial mass to be worth exploring IETF work on it. > From dwing@cisco.com Thu Aug 27 12:04:08 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 62B2C3A6E16 for ; Thu, 27 Aug 2009 12:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.667 X-Spam-Level: X-Spam-Status: No, score=-6.667 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 zNsnoYk2nFvC for ; Thu, 27 Aug 2009 12:04:07 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 751FB28C58A for ; Thu, 27 Aug 2009 12:04:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,287,1249257600"; d="scan'208";a="376710702" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 27 Aug 2009 19:04:08 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7RJ48b0018334; Thu, 27 Aug 2009 12:04:08 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7RJ48US021033; Thu, 27 Aug 2009 19:04:08 GMT From: "Dan Wing" To: "'Bryan Ford'" , References: <549FD1CD-5433-45E6-83A2-C69345E1D5EC@mpi-sws.org> Date: Thu, 27 Aug 2009 12:04:08 -0700 Message-ID: <00ce01ca2749$27940b70$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcoRJWk0NfWGIQadR4i/q7KGZfMKgQWI1uHw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6029; t=1251399848; x=1252263848; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[tae]=20Negotiation=20BOF=20charter=20d raft |Sender:=20; bh=krroAkzumArr6XvNLtUHDALVWHegFl643m1t0D0Lgrs=; b=HwFwwL82EFxFcPW6l247U0k8RTFfzvD3MB+A+HCHV1qkNYnKnr96C/+HVO 6c9vfzyoUiEJiHxSXsqiAxwaT3PyJlSM4YGT7J0xB6mqjqkW+VDYDaIOcOq8 LoPRsC85Uq; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: ayourtch@cisco.com Subject: Re: [tae] Negotiation BOF charter draft 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: Thu, 27 Aug 2009 19:04:08 -0000 > -----Original Message----- > From: tae-bounces@ietf.org [mailto:tae-bounces@ietf.org] On > Behalf Of Bryan Ford > Sent: Thursday, July 30, 2009 7:53 AM > To: tae@ietf.org > 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 > tae@ietf.org > https://www.ietf.org/mailman/listinfo/tae > From dwing@cisco.com Mon Aug 31 17:52:37 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 92C9F3A69E1 for ; Mon, 31 Aug 2009 17:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.329 X-Spam-Level: X-Spam-Status: No, score=-6.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 abIEi0K5Qn0M for ; Mon, 31 Aug 2009 17:52:36 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 713F23A66B4 for ; Mon, 31 Aug 2009 17:52:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,308,1249257600"; d="scan'208";a="379318517" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 01 Sep 2009 00:52:45 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n810qj6k025008; Mon, 31 Aug 2009 17:52:45 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n810qjdY007141; Tue, 1 Sep 2009 00:52:45 GMT From: "Dan Wing" To: "'Bryan Ford'" , References: <549FD1CD-5433-45E6-83A2-C69345E1D5EC@mpi-sws.org> Date: Mon, 31 Aug 2009 17:52:44 -0700 Message-ID: <043601ca2a9e$84b36870$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcoRJWk0NfWGIQadR4i/q7KGZfMKgQZd9wmQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5628; t=1251766365; x=1252630365; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[tae]=20Negotiation=20BOF=20charter=20d raft |Sender:=20; bh=nrKjIMzeYvy2SRZvH2slIC3Apc0Der5E10tIbv2wAxI=; b=G92CdZuT60l8E9RjKYJLj4AliVt4F6WntqrOXzpqI0rmrwgb9cFvAlz8aP oIkvhXf61OOsRya+UbKoK37a8VsOczB5iWuLq8P2H9nVgUZ222yi4Ay7hYZM pLj0lINzoK; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: ayourtch@cisco.com Subject: Re: [tae] Negotiation BOF charter draft 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: Tue, 01 Sep 2009 00:52:37 -0000 > -----Original Message----- > From: tae-bounces@ietf.org [mailto:tae-bounces@ietf.org] On > Behalf Of Bryan Ford > Sent: Thursday, July 30, 2009 7:53 AM > To: tae@ietf.org > 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... > > --- > > 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 "unavoidable due to middleboxes." > 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. Do you want to throw multiple interfaces into that (already long) list of reasons we may see explosive growth in such probes? > 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 That sounds good. > 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 Andrew Yourtchenko and I will have a DNS-based negotiation protocol ready for review 'soon'. -d > > --- > > Comments? > Bryan > > _______________________________________________ > tae mailing list > tae@ietf.org > https://www.ietf.org/mailman/listinfo/tae >