[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