[Spud] Balancing optimiizations (was SPUD Scope)

Ted Hardie <ted.ietf@gmail.com> Mon, 08 June 2015 16:21 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E8B1B303B for <spud@ietfa.amsl.com>; Mon, 8 Jun 2015 09:21:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Level:
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 KI4onoiG4Vnb for <spud@ietfa.amsl.com>; Mon, 8 Jun 2015 09:21:12 -0700 (PDT)
Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF241B3039 for <spud@ietf.org>; Mon, 8 Jun 2015 09:21:11 -0700 (PDT)
Received: by wgbgq6 with SMTP id gq6so107631243wgb.3 for <spud@ietf.org>; Mon, 08 Jun 2015 09:21:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=NyI0ZvP6+QL9f8Ob/eEdTWWYx0hwTTm9izJEfv0uqwU=; b=G4zLLsdEtg5B0CCFYzUOg0UFlv7lkvsg3SN9zsDZS1w949VxjU5HZxoX+CBkl/1lzw wqbQoQgf1hYsIs4vInPmqTvgrlQCuJ70ivJovp+FL9KB7wffhYsNwJLH+UveLTjggswN mEao1/fhxXsu5lJBCzVMPzl7YJ6b8O4UkjNyGHkye2jHnyH3tDg8mxP26WpPCDsSnAOy +wkMBYXKVMtM/oO8ITs1bXFBJRQ25CeUeu6a6k8qZm7Av/VhnFpUQ7+RZnXH4mi60k+d wq0TnM1+D+CkbmXiubgVAE2lDFSixl4oCvPD0jdaFrizGSHtEFY4KF4JmsAg972L/Zb/ 7Jwg==
MIME-Version: 1.0
X-Received: by 10.194.187.170 with SMTP id ft10mr33878686wjc.26.1433780470561; Mon, 08 Jun 2015 09:21:10 -0700 (PDT)
Received: by 10.194.25.74 with HTTP; Mon, 8 Jun 2015 09:21:10 -0700 (PDT)
Date: Mon, 8 Jun 2015 09:21:10 -0700
Message-ID: <CA+9kkMBR5_wEo0HPnJwmR9BacwsL9f7Yp2w_yrS=v=G90bh7gw@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: "spud@ietf.org" <spud@ietf.org>
Content-Type: multipart/alternative; boundary=047d7bb03a92a241b30518040771
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/6ha7oyNrOrvhyM1M8phK28q3Rsc>
Subject: [Spud] Balancing optimiizations (was SPUD Scope)
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jun 2015 16:21:18 -0000

Howdy,

So, reading through
​the comment thread on scope, I felt again that we're missing the character
of the work as experimental and, more importantly, as supporting
experimentation.

The question we're asking, at its core, is how do we increase the ability
of protocols to explore different congestion control, pacing, and
reliability parameters (a.k.a. how do we evolve the protocols using the
network)?

It has become apparent that some of that experimentation is going on in
user space, using UDP as a substrate.  SPUD is trying to extend that
substrate to provide a common mechanism for indicating specific packets are
grouped together, so that experiments can determine whether network
treatment can vary when they are so grouped.  The extensions beyond that
are to determine whether network treatment can be influenced by semantics
attached to the grouping.  The core commands are similar to those already
shared by TCP:  open, close, ack, normal data.

​All the declaration bits after that point are potential optimizations that
can be dropped​ at any time by any party, but the experiments the
availability of those bits allow you to run are important.  A core question
behind those experiements is  "Can you tell the path something the elicits
specific network treatment without disclosing more than the desired
treatment?".  The corresponding question is "Can how the application puts
traffic onto a path vary in response to path indications without simply
trusting those declarations?"  The experiments may end up answering those
questions with "Yes" or "No", but we'd like to run the experiments to see.

No one thinks SPUD is done or ready for standardization; it's not.
​It's context for a set of experiments, not a solution. The result may tell
us that the grouping mechanism does no good and the whole effort should
drop.  It may tell us that the grouping is useful and some, but not all, of
the core commands work.  It may tell us that only declarative bits like
"discard-preferred" are safe.​


But if we can't experiment at all with what common substrates would look
like, we know our evolution has limits.  Those limits don't necessarily
produce better privacy results; it just pushes the problem into each
protocol built on UDP and ossifies whatever choices made it through
middleboxes already.
​I think the community should see if that's better before deciding it is so.
​


No hats,

Ted