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