Re: [Udp35] Trying to learn about udp35
Jana Iyengar <jri@google.com> Wed, 25 June 2014 16:17 UTC
Return-Path: <jri@google.com>
X-Original-To: udp35@ietfa.amsl.com
Delivered-To: udp35@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B521B2D24 for <udp35@ietfa.amsl.com>; Wed, 25 Jun 2014 09:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.03
X-Spam-Level:
X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAPBkyQUFUIh for <udp35@ietfa.amsl.com>; Wed, 25 Jun 2014 09:17:19 -0700 (PDT)
Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C76821B29EB for <udp35@ietf.org>; Wed, 25 Jun 2014 09:17:18 -0700 (PDT)
Received: by mail-qg0-f47.google.com with SMTP id q108so1881304qgd.34 for <udp35@ietf.org>; Wed, 25 Jun 2014 09:17:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IDFb99teEybHbMe5iAj7GPSABYustxI9PfwfkCMqnD0=; b=dRMsoUPqKF3pO87jG8747nshkNxPd4a8USmNVJXBIYAtFMn7a78HG//JBXeY5H3ULt YFot2NsKjANIQtRvd+9/KBR1MVp+lvZwMmhLnKO3s5BX5HVT2q4Ju6abmcO/aelUheNx xLoAuYRHC9oNAZ5saYsHaLecNmhfuGtlr4uTm8ODZTxetR/TWtLR1QA9lkjLkUdAT4Td wPQP3nxPMSKLLxhzBOCtu0WlZiF2R8SwIyo24r6yTuwF8PwJQ9oknwZTQAEjnGt1DfNJ OWs5/VcPEzWUIytjsZX6Uf4ryucc7UivlSZVM9FqKHz1LpzSygS4BO2sOV6KcmD1+ENd lN8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IDFb99teEybHbMe5iAj7GPSABYustxI9PfwfkCMqnD0=; b=MRbr2raLd8U5ct50ZcgH4qnGvmeSDBWUwyv7/SAK1P1yYxqsBfrHML4hwDpAto2+LU JDo9fGt508J/iv1lImwBgBMdP3YZ2/sGWfqqPPOFwFImhM2eCd9WdjlcP3VT6i+OL6qD VduBvJbFPrGLnBFfwKM2IqX9iFiQCRubfDamIKGT/++6SKeM2d9K3IDUo+ydseE+ty/H ZfyIAU7xPDWFtNQPle5IJ0wLTsM+S5P3uU+ixhzEJpP4uBUKU1KZZGHSy4oXccl12XHR xMnJ6IybWE/zYjanEQgN5DbbcUsczinNdR7EnRoiH8OLt2oRuSBuk9FYd75zlcgbIghe 6iKA==
X-Gm-Message-State: ALoCoQnYlVLrt97aP2lm4ONBuqmk6/YMgG9t6uULrudwD0ioA0zylVUTRB50ociHawWgpoqVKy+L
MIME-Version: 1.0
X-Received: by 10.224.2.196 with SMTP id 4mr3877315qak.60.1403713038067; Wed, 25 Jun 2014 09:17:18 -0700 (PDT)
Received: by 10.96.156.99 with HTTP; Wed, 25 Jun 2014 09:17:17 -0700 (PDT)
In-Reply-To: <f4b149c2de45c25d435ab76f60808b8b.squirrel@www.erg.abdn.ac.uk>
References: <CAGD1bZYA4esRRYfSeRjBnJv4pGyRyg3x7xBBd_C=-NfxDD9rpA@mail.gmail.com> <537A3BA5.2070406@gmail.com> <CAGD1bZas6ur_uS=YaPedXqLCaVcxk+kGo=bO+axFQdTJaB5eHw@mail.gmail.com> <E81DA188-091C-4E23-BAC7-09702F9C66E3@trammell.ch> <9F7FA388-3AA3-496F-B727-E2D8872B82C5@ifi.uio.no> <989971F8-203E-4087-87EF-CEA1214DE9C9@trammell.ch> <9763C6AC-C8D6-4DE4-BAA0-1BD4595E4EB0@ifi.uio.no> <EB090BFC-2587-4CF8-97AD-E410FBB29C67@trammell.ch> <EF1A49FF-40A9-4DFF-A62D-F59AD7B0499A@ifi.uio.no> <CAGD1bZY7FpUi3YpebOSZw-vQgBXYMOpOT3rPi5Ct2_477grAYQ@mail.gmail.com> <f4b149c2de45c25d435ab76f60808b8b.squirrel@www.erg.abdn.ac.uk>
Date: Wed, 25 Jun 2014 09:17:17 -0700
Message-ID: <CAGD1bZYDBiUcQBiE73zVEvWAR02y7FruNkk4-OdYArufDTK2PA@mail.gmail.com>
From: Jana Iyengar <jri@google.com>
To: gorry@erg.abdn.ac.uk
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/udp35/bXtI4j8SVp1b5AFgft7A5ZMVt20
Cc: Brian Trammell <ietf@trammell.ch>, Spencer Dawkins <spencerdawkins.ietf@gmail.com>, Michael Welzl <michawe@ifi.uio.no>, udp35@ietf.org
Subject: Re: [Udp35] Trying to learn about udp35
X-BeenThere: udp35@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Life beyond UDP <udp35.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/udp35>, <mailto:udp35-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/udp35/>
List-Post: <mailto:udp35@ietf.org>
List-Help: <mailto:udp35-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/udp35>, <mailto:udp35-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Jun 2014 16:17:21 -0000
Also, FWIW, here's a draft that Bryan Ford and I wrote up a while ago, for the first MPTCP wg meeting in Stockholm. The intent was to provide an architectural basis for the work in the wg, and some of it made it into the MPTCP Architecture RFC. Perhaps there's room for this conversation here. I was a bit disappointed that more of it didn't make it into the MPTCP work. See: http://tools.ietf.org/html/draft-iyengar-ford-tng-00. 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. - jana
- [Udp35] Trying to learn about udp35 Jana Iyengar
- Re: [Udp35] Trying to learn about udp35 Joe Hildebrand (jhildebr)
- Re: [Udp35] Trying to learn about udp35 Spencer Dawkins
- Re: [Udp35] Trying to learn about udp35 Jana Iyengar
- Re: [Udp35] Trying to learn about udp35 Brian Trammell
- Re: [Udp35] Trying to learn about udp35 Michael Welzl
- Re: [Udp35] Trying to learn about udp35 Joe Hildebrand (jhildebr)
- Re: [Udp35] Trying to learn about udp35 Michael Welzl
- Re: [Udp35] Trying to learn about udp35 Brian Trammell
- Re: [Udp35] Trying to learn about udp35 Michael Welzl
- Re: [Udp35] Trying to learn about udp35 Spencer Dawkins
- Re: [Udp35] Trying to learn about udp35 Michael Welzl
- Re: [Udp35] Trying to learn about udp35 Brian Trammell
- Re: [Udp35] Trying to learn about udp35 Michael Welzl
- Re: [Udp35] Trying to learn about udp35 Jana Iyengar
- Re: [Udp35] Trying to learn about udp35 Brian Trammell
- Re: [Udp35] Trying to learn about udp35 gorry
- Re: [Udp35] Trying to learn about udp35 Jana Iyengar
- Re: [Udp35] Trying to learn about udp35 Jana Iyengar
- Re: [Udp35] Trying to learn about udp35 Jana Iyengar
- Re: [Udp35] Trying to learn about udp35 Gorry Fairhurst