From janardhan.iyengar@fandm.edu Mon Jul 6 15:45:04 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 73FFD28C3A2; Mon, 6 Jul 2009 15:45:04 -0700 (PDT) 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 0NcFmJhlKoXh; Mon, 6 Jul 2009 15:45:03 -0700 (PDT) Received: from zimfe2.fandm.edu (zimfe2.fandm.edu [155.68.1.75]) by core3.amsl.com (Postfix) with ESMTP id 100093A6819; Mon, 6 Jul 2009 15:45:02 -0700 (PDT) Received: from surutti.fandm.edu (pool-72-95-58-210.hrbgpa.east.verizon.net [72.95.58.210]) by zimfe2.fandm.edu (Postfix) with ESMTP id D1F0811687F8; Mon, 6 Jul 2009 18:44:43 -0400 (EDT) Message-ID: <4A527E5A.3090801@fandm.edu> Date: Mon, 06 Jul 2009 18:44:42 -0400 From: Janardhan Iyengar Organization: Franklin & Marshall College User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: tsv-area@ietf.org, multipathtcp@ietf.org, tae@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tae] A Next Generation Transport Services Architecture 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: Mon, 06 Jul 2009 22:45:04 -0000 (Apologies for cross-posting) Dear all, We have uploaded a draft describing our proposed transport re-architecture, with its relevance and implications to multipath transport. Our hope is that this draft starts (or continues?) a conversation on a refactoring of the transport layer to accomodate new services and network elements. We also hope that this draft serves as a starting point for discussions about multipath transport and for an architectural framework within which to place multipath-tcp work at the IETF. ----------- A Next Generation Transport Services Architecture http://www.ietf.org/internet-drafts/draft-iyengar-ford-tng-00.txt Abstract: While there is substantial community interest in next-generation multipath-capable Internet transports, evolutionary pressures have gradually eroded the simplicity of the Internet's original transport architecture to a point where it is no longer realistically applicable to new tranports. This document proposes a new architectural framework for next-generation multipath-capable transport protocols, focusing immediately on multipath TCP but taking care to allow for generalization to other multipath-capable transports. The architecture places emphasis on enabling new multipath features in a safe, TCP-friendly, and backward-compatible fashion, retaining full interoperability with both existing applications and existing network infrastructure, and enabling reuse of existing protocols as much as possible while providing incremental deployment paths to new, more powerful and/or more efficient protocols. The architecture re-establishes the long-lost principles of end-to-end reliability and fate sharing, in the presence of existing and future network middleboxes, and enables the deployment of transport-neutral end-to-end protection without interfering with these policy-enforcing or performance-enhancing middleboxes. This document describes architecture goals, a layering model supporting these goals, abstract properties of the interfaces between the architecture's new layers, general approaches to multipath congestion control and how they fit into the architecture, realistic protocol design and incremental deployment paths, and ways in which this document complements and relates to ongoing protocol design activities in the IETF. ------------ Comments and thoughts welcome! - jana -- Janardhan Iyengar Assistant Professor, Computer Science Franklin & Marshall College http://www.fandm.edu/jiyengar From baford@mpi-sws.org Mon Jul 27 10:24:06 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 EB64728C36B; Mon, 27 Jul 2009 10:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 Fi0r0BddjmX8; Mon, 27 Jul 2009 10:24:05 -0700 (PDT) Received: from hera.mpi-sb.mpg.de (infao0809.mpi-sb.mpg.de [139.19.1.49]) by core3.amsl.com (Postfix) with ESMTP id 6620528C36D; Mon, 27 Jul 2009 10:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mpi-sb.mpg.de; s=mail200803; h=Message-Id:From:To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:Cc; bh=Hzulz BWMk63GDaYqJlZdprz/2BB1mwygx1oZTqXIvSk=; b=CiCW9MA8P6Zd42GNyuIdU yoLncaoZDX9HUEmDGEpYYYMtqvj1FPZxYHFWVXjuqFsghxfUr6z//T5kI2gxvTgq 3XujH/DBlfX2L6Pph3r5LRTtewASAPTEmWvrg3ufd/8FB6nlZ7LPqhta7cmkAsRe fYqYUx6bfy3lXycDYddmIM= Received: from newmaniac.mpi-sb.mpg.de ([139.19.1.26]:39299) by hera.mpi-sb.mpg.de (envelope-from ) with esmtp (Exim 4.69) id 1MVTul-0004GT-QN; Mon, 27 Jul 2009 19:23:10 +0200 Received: from dhcp-105a.meeting.ietf.org ([130.129.16.90]:59602) by newmaniac.mpi-sb.mpg.de with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1MVTul-0006oP-5N; Mon, 27 Jul 2009 19:23:07 +0200 Message-Id: <0AFEFBE9-E3A6-45FE-8F6A-B22E3CA7AA11@mpi-sws.org> From: Bryan Ford To: tae@ietf.org, tsv-area@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 27 Jul 2009 19:23:06 +0200 X-Mailer: Apple Mail (2.935.3) Cc: Michael Tuexen , Scott Brim , Christian Vogt Subject: [tae] Transport Architecture Evolution mailing list and Bar-BOF 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: Mon, 27 Jul 2009 17:24:07 -0000 For those interested in further discussing broader issues of transport architecture evolution such as those that we discussed in today's TSVAREA meeting: (1) For those not yet aware, there's an IETF mailing list we started a while ago for these types of discussions: "Transport Architecture Evolution" https://www.ietf.org/mailman/listinfo/tae (2) Some of us are getting together for an unofficial "bar-BOF" tomorrow (Tuesday) lunchtime, at 11:30, directly in front of the conference center (along the street), to find a place and discuss architecture issues over lunch. Likely topics include layering model stuff, negotiation, naming/address-neutrality in the transport layer, etc. - it's open-ended at this point, but we'd at least like to identify some of the most promising/urgent next steps. Since lunch period is short, we'll leave promptly no later than 11:40, so be on time. :) Thanks, Bryan From baford@mpi-sws.org Mon Jul 27 10:33:33 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 CE5203A6CDE; Mon, 27 Jul 2009 10:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.629 X-Spam-Level: X-Spam-Status: No, score=-5.629 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 tNEIbmEsY5xW; Mon, 27 Jul 2009 10:33:32 -0700 (PDT) Received: from hera.mpi-sb.mpg.de (infao0809.mpi-sb.mpg.de [139.19.1.49]) by core3.amsl.com (Postfix) with ESMTP id 1F4843A6CD7; Mon, 27 Jul 2009 10:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mpi-sb.mpg.de; s=mail200803; h=Message-Id:From:To:Content-Type: Mime-Version:Subject:Date:Cc; bh=xLlO7q/Bfer9IGDL36UVgqB8Ul2qEFm 6a6O6YhBTTyQ=; b=ekhWBPu/cnxSgZW2bkwRdNSq+Jsr6z+dDUH+G5KSs+DL7dR tYEUpvvq/fku2dbG7Go3sy+auF3wSniEFFbk/l3Nrp9Ov7sYSJAwD4Qru5r12VkK ftNIFh84E31532ZHDO/sSNpRIIcPu8COdOkHhV+lgqNUwl1adbWoiQZUUkmQ= Received: from infao0525.mpi-sb.mpg.de ([139.19.1.26]:43386 helo=newmaniac.mpi-sb.mpg.de) by hera.mpi-sb.mpg.de (envelope-from ) with esmtp (Exim 4.69) id 1MVU3b-0006dw-0d; Mon, 27 Jul 2009 19:32:18 +0200 Received: from dhcp-105a.meeting.ietf.org ([130.129.16.90]:59691) by newmaniac.mpi-sb.mpg.de with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1MVU3a-0006tO-2P; Mon, 27 Jul 2009 19:32:14 +0200 Message-Id: <77BFFA0D-5BDD-4DA7-AD9D-DBC65DD017F8@mpi-sws.org> From: Bryan Ford To: Dan Wing , Andrew Yourtchenko , Preethi Natarajan Content-Type: multipart/alternative; boundary=Apple-Mail-114--174206131 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 27 Jul 2009 19:32:13 +0200 X-Mailer: Apple Mail (2.935.3) Cc: tae@ietf.org, tsv-area@ietf.org Subject: [tae] Negotiation discussion 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: Mon, 27 Jul 2009 17:33:34 -0000 --Apple-Mail-114--174206131 Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Dan, Andrew, Preethi, This is in response to your tsvarea presentation today and your draft-=20= wing-http-new-tech-00. As I commented after your talk, I think the whole negotiation topic =20 that you brought up is incredibly important. I think the specific =20 approach you're proposing is very sensible and perhaps really the only =20= realistic option in the short term, and certainly worth pursuing =20 further, likely in the application area. In the long term as alternatives explode, I think we'll need something =20= more general and scalable, and that can deal with both transport-level =20= and application-level negotiation. Jana and I actually just recently =20= wrote a draft paper on this topic - our version is pie-in-the-sky and =20= researchy, but I hope it might be interesting as a potential longer-=20 term approach to this problem. (And your short-term approach will =20 needed to get to such a long-term approach. :) ) Here is the title, =20 abstract, and URL: "An Ef=EF=AC=81cient Cross-Layer Negotiation Protocol" http://bford.info/pub/net/nego.pdf Internet evolution often depends on either inserting new protocol =20 layers or upgrading existing layers to new protocols, but both of =20 these evolutionary paths are obstructed by the difficulty and =20 inefficiency of determining which protocols a pair of hosts mutually =20 support and prefer. We propose a novel cross-layer Negotiation =20 Protocol that sets up a complete stack of connection-oriented =20 protocols at once, concurrently performing handshaking for multiple =20 layers and choosing among alternative protocols for each layer in as =20 few round trips as possible, often just one. The initiator proposes a =20= protocol graph explicitly encoding possible configurations along with =20= protocol-specific handshake data; the peers then prune, refine, and =20 atomically commit to a final configuration, exchanging messages over a =20= specialized transport that can operate in-line with the negotiated =20 protocol stack. Although a practical Negotiation Protocol presents =20 many challenges, our initial exploration suggests that these =20 challenges are solvable, and we believe addressing them is a necessary =20= step toward a more evolvable Internet. We might try to talk about these negotiation ideas tomorrow at the TAE =20= Bar-BOF; see my previous message on tae and tsv-area... Thanks, Bryan --Apple-Mail-114--174206131 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dan, Andrew, = Preethi,

This is in response to your tsvarea = presentation today and = your draft-wing-http-new-tech-00.

As I = commented after your talk, I think the whole negotiation topic that you = brought up is incredibly important.  I think the specific approach = you're proposing is very sensible and perhaps really the only realistic = option in the short term, and certainly worth pursuing further, likely = in the application area.

In the long term as = alternatives explode, I think we'll need something more general and = scalable, and that can deal with both transport-level and = application-level negotiation.  Jana and I actually just recently = wrote a draft paper on this topic - our version is pie-in-the-sky and = researchy, but I hope it might be interesting as a potential longer-term = approach to this problem.  (And your short-term approach will = needed to get to such a long-term approach. :) ) =  Here is the title, abstract, and URL:<= /div>

"An Ef=EF=AC=81cient = Cross-Layer Negotiation Protocol
http://bford.info/pub/net/nego.pdf
Internet evolution often depends on either = inserting new protocol layers or upgrading existing layers to new = protocols, but both of these evolutionary paths are = obstructed by the difficulty and inefficiency of = determining which protocols a pair of hosts mutually support = and prefer.  We propose a novel cross-layer Negotiation = Protocol that sets up a complete stack of connection-oriented = protocols at once, concurrently performing handshaking for multiple = layers and choosing among alternative protocols for each = layer in as few round trips as possible, often just = one.  The initiator proposes a protocol graph explicitly = encoding possible configurations along with protocol-specific = handshake data; the peers then prune, refine, and atomically commit = to a final configuration, exchanging messages over a specialized = transport that can operate in-line with the negotiated protocol = stack. Although a practical Negotiation Protocol presents many = challenges, our initial exploration suggests that these challenges = are solvable, and we believe addressing them is a necessary = step toward a more evolvable Internet.

We = might try to talk about these negotiation ideas tomorrow at the TAE = Bar-BOF; see my previous message on tae and = tsv-area...

Thanks,
Bryan

= --Apple-Mail-114--174206131-- From baford@mpi-sws.org Wed Jul 29 00:44:07 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 0036A3A6DA7 for ; Wed, 29 Jul 2009 00:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.042 X-Spam-Level: X-Spam-Status: No, score=-6.042 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 wWUTt1xBikpg for ; Wed, 29 Jul 2009 00:44:05 -0700 (PDT) Received: from hera.mpi-sb.mpg.de (hera.mpi-sb.mpg.de [139.19.1.49]) by core3.amsl.com (Postfix) with ESMTP id DEE283A6E89 for ; Wed, 29 Jul 2009 00:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mpi-sb.mpg.de; s=mail200803; h=Message-Id:From:To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date; bh=/oSaIqwM suKVsMOHULz+QqiMpioDmdFvjmVYqr4q+Us=; b=cCaj15SNuY7qt5pjRFl05JZg 3P4CqUqOhQbZVc04TnkElb0hqLn9T9CvOSiMJQvUJNR6OjXXpinLSLkH1iTFktN2 rMRIHdzmOPnYLbjGczdBrNx8Ji2rtlLJUCsqYL3fGoLAXhss+DJkj4DL7kaKuQ7T pUY/p1vWvpGyiBJQxmk= Received: from newmaniac.mpi-sb.mpg.de ([139.19.1.26]:35787) by hera.mpi-sb.mpg.de (envelope-from ) with esmtp (Exim 4.69) id 1MW3pN-0005uC-30 for tae@ietf.org; Wed, 29 Jul 2009 09:44:00 +0200 Received: from dhcp-105a.meeting.ietf.org ([130.129.16.90]:55265) by newmaniac.mpi-sb.mpg.de with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1MW3pM-0003BH-NS for tae@ietf.org; Wed, 29 Jul 2009 09:43:56 +0200 Message-Id: <8272C647-9E3C-4C15-BCF0-01DB52A90742@mpi-sws.org> From: Bryan Ford To: tae@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 29 Jul 2009 09:43:55 +0200 X-Mailer: Apple Mail (2.935.3) Subject: [tae] TAE bar-BOF summary 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: Wed, 29 Jul 2009 07:44:07 -0000 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. Meta-topic 2: where to go with these transport architecture evolution discussions in the future? In particular, should we keep them informal - on the TAE mailing list and in unofficial bar-BOFs whenever people are getting together - or whether we should try to make it more "official" in some way. One possibility we discussed briefly was trying to build a new (or revive an old) IRTF working group; it seemed that might be a possibility, but such a group's objective would have to be nailed down more specifically in order to form a viable charter. Overall, I think the consensus was that we should keep looking at this possibility, but that it's not necessarily very urgent, so we'll stick to mailing lists and informal bar-BOFs for now. Topic: Negotiation. As mentioned above, we concluded that there seems to be a lot of interest in concrete near-term work in this direction, and we spent quite a bit of time discussing approaches, both technical (i.e., what the protocol(s) might look like) and procedural (how to move forward and propose a concrete BOF on this topic). On the technical side, it seems that what we need is (a) a short-term solution along the lines of the "Happy Eyeballs" draft that will help us get to a longer-term solution, and (b) a long-term solution that will scale as the number of potential alternative protocols or protocol versions increases, across all relevant layers: e.g., Network Layer (IPv4 vs IPv6), Transport (TCP vs SCTP etc.), and potentially Application layer (negotiation among different application protocols). Some open issues are the precise scope for a negotiation BOF/WG, and whether negotiation should operate out-of-band (e.g., via DNS) or in-band with the negotiated traffic. The main procedural action-item we concluded on in the end was that Jana and I will come up with a draft charter for a negotiation BOF, then we'll iterate on it on it a few times on this (TAE) list, and seek approval for an official negotiation BOF in Hiroshima. Thanks, Bryan From menth@informatik.uni-wuerzburg.de Wed Jul 29 15:44:50 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 9D7DA3A702D for ; Wed, 29 Jul 2009 15:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 RE2oJiLtmRKt for ; Wed, 29 Jul 2009 15:44:49 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 6AA323A7049 for ; Wed, 29 Jul 2009 15:44:48 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id DAB7119910A; Thu, 30 Jul 2009 00:44:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id CDFAB1990E7; Thu, 30 Jul 2009 00:44:49 +0200 (CEST) Received: from [78.64.88.12] (host-78-64-88-12.homerun.telia.com [78.64.88.12]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 86D85A07DF; Thu, 30 Jul 2009 00:44:49 +0200 (CEST) Message-ID: <4A70D0E2.5000808@informatik.uni-wuerzburg.de> Date: Thu, 30 Jul 2009 00:44:50 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) 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-Virus-Scanned: by amavisd-new at uni-wuerzburg.de 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: menth@informatik.uni-wuerzburg.de List-Id: Transport Architecture Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 22:44:50 -0000 Hi Bryan, I have missed the discussion since I arrived only on Wednesday night. What do you exactly understand by "negotiation"? Could you give an example? Regards, Michael Bryan Ford schrieb: > 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. > > Meta-topic 2: where to go with these transport architecture evolution > discussions in the future? In particular, should we keep them > informal - on the TAE mailing list and in unofficial bar-BOFs whenever > people are getting together - or whether we should try to make it more > "official" in some way. One possibility we discussed briefly was > trying to build a new (or revive an old) IRTF working group; it seemed > that might be a possibility, but such a group's objective would have > to be nailed down more specifically in order to form a viable > charter. Overall, I think the consensus was that we should keep > looking at this possibility, but that it's not necessarily very > urgent, so we'll stick to mailing lists and informal bar-BOFs for now. > > Topic: Negotiation. As mentioned above, we concluded that there > seems to be a lot of interest in concrete near-term work in this > direction, and we spent quite a bit of time discussing approaches, > both technical (i.e., what the protocol(s) might look like) and > procedural (how to move forward and propose a concrete BOF on this > topic). On the technical side, it seems that what we need is (a) a > short-term solution along the lines of the "Happy Eyeballs" draft that > will help us get to a longer-term solution, and (b) a long-term > solution that will scale as the number of potential alternative > protocols or protocol versions increases, across all relevant layers: > e.g., Network Layer (IPv4 vs IPv6), Transport (TCP vs SCTP etc.), and > potentially Application layer (negotiation among different application > protocols). Some open issues are the precise scope for a negotiation > BOF/WG, and whether negotiation should operate out-of-band (e.g., via > DNS) or in-band with the negotiated traffic. The main procedural > action-item we concluded on in the end was that Jana and I will come > up with a draft charter for a negotiation BOF, then we'll iterate on > it on it a few times on this (TAE) list, and seek approval for an > official negotiation BOF in Hiroshima. > > Thanks, > Bryan > > _______________________________________________ > tae mailing list > tae@ietf.org > https://www.ietf.org/mailman/listinfo/tae -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From bless@tm.uka.de Wed Jul 29 23:18: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 5F8133A6D2E for ; Wed, 29 Jul 2009 23:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 fR9WXErYaOoi for ; Wed, 29 Jul 2009 23:18:23 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id 086383A6B7E for ; Wed, 29 Jul 2009 23:18:23 -0700 (PDT) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1MWOxx-0000Vw-40; Thu, 30 Jul 2009 08:18:15 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps port 25 id 1MWOxw-0004r3-Ut; Thu, 30 Jul 2009 08:18:13 +0200 Received: from vorta.tm.uka.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:21b:fcff:fe96:fe02]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id D35802FC008; Thu, 30 Jul 2009 08:18:12 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by vorta.tm.uka.de (Postfix) with ESMTP id 754081035C; Thu, 30 Jul 2009 08:18:12 +0200 (CEST) Message-ID: <4A713B23.6040700@tm.uka.de> Date: Thu, 30 Jul 2009 08:18:11 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: menth@informatik.uni-wuerzburg.de References: <8272C647-9E3C-4C15-BCF0-01DB52A90742@mpi-sws.org> <4A70D0E2.5000808@informatik.uni-wuerzburg.de> In-Reply-To: <4A70D0E2.5000808@informatik.uni-wuerzburg.de> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1248934695.859303000 Cc: tae@ietf.org Subject: Re: [tae] TAE bar-BOF summary 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, 30 Jul 2009 06:18:24 -0000 Hi Michael, Michael Menth wrote: > I have missed the discussion since I arrived only on Wednesday night. > What do you exactly understand by "negotiation"? Could you give an example? As far as I understood, you will negotiate available transport protocols, ports, etc. For instance for SIP transport this is done via DNS, using NAPTR and SRV records, but that's probably not the best or most efficient way to do it. Furthermore, there are more and more applications that could use the different available transports. So how do you find out whether a web server supports http over sctp or http over tls/tcp etc.? Probing may cause long timeouts and thus setup delays. See: http://www.ietf.org/mail-archive/web/tsv-area/current/msg00345.html >> solution that will scale as the number of potential alternative >> protocols or protocol versions increases, across all relevant layers: >> e.g., Network Layer (IPv4 vs IPv6), Transport (TCP vs SCTP etc.), and >> potentially Application layer (negotiation among different application >> protocols). Some open issues are the precise scope for a negotiation >> BOF/WG, and whether negotiation should operate out-of-band (e.g., via >> DNS) or in-band with the negotiated traffic. The main procedural >> action-item we concluded on in the end was that Jana and I will come >> up with a draft charter for a negotiation BOF, then we'll iterate on >> it on it a few times on this (TAE) list, and seek approval for an >> official negotiation BOF in Hiroshima. Regards, Roland From baford@mpi-sws.org Thu Jul 30 07:52:44 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 BF8523A6C71 for ; Thu, 30 Jul 2009 07:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.125 X-Spam-Level: X-Spam-Status: No, score=-6.125 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 jDVqQ9ytwoYp for ; Thu, 30 Jul 2009 07:52:43 -0700 (PDT) Received: from hera.mpi-sb.mpg.de (hera.mpi-sb.mpg.de [139.19.1.49]) by core3.amsl.com (Postfix) with ESMTP id 2E0453A69D2 for ; Thu, 30 Jul 2009 07:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mpi-sb.mpg.de; s=mail200803; h=Message-Id:From:To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References; bh=dZaKl0zdm8t8hHbEbWQl0M570B/WQB70bK1LUTywrPw=; b=PiYNPNzWGr4ru KA4hg48njeUIAColIPQQ80IKfjIyfDTPClX2SoMdCdj0k1Q826TakUh2djkdpWvW hg8eOeqmv6Qt1qyYt7SYpv8SfHkX1BYej5xYe/VAEhi/PT1GRDnbKH6OoXPRPcPR Jl/dhSFvjcGjiDXUORhZuLIZx6GDjE= Received: from newmaniac.mpi-sb.mpg.de ([139.19.1.26]:46638) by hera.mpi-sb.mpg.de (envelope-from ) with esmtp (Exim 4.69) id 1MWWzn-0002LY-Hn for tae@ietf.org; Thu, 30 Jul 2009 16:52:42 +0200 Received: from dhcp-105a.meeting.ietf.org ([130.129.16.90]:62265) by newmaniac.mpi-sb.mpg.de with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1MWWzn-000679-61 for tae@ietf.org; Thu, 30 Jul 2009 16:52:39 +0200 Message-Id: From: Bryan Ford To: tae@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 16:52:38 +0200 References: <549FD1CD-5433-45E6-83A2-C69345E1D5EC@mpi-sws.org> X-Mailer: Apple Mail (2.935.3) Subject: [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, 30 Jul 2009 14:52:44 -0000 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 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