IETF Logo Mail Archive

Re: [Spud] No. Operators don't need SPUD for mobile network management

Tom Herbert <tom@herbertland.com> Wed, 27 July 2016 03:05 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD6E12B04B for <spud@ietfa.amsl.com>; Tue, 26 Jul 2016 20:05:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 m9TyzQaP3pTq for <spud@ietfa.amsl.com>; Tue, 26 Jul 2016 20:05:02 -0700 (PDT)
Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 9233112D9AF for <spud@ietf.org>; Tue, 26 Jul 2016 20:05:02 -0700 (PDT)
Received: by mail-it0-x22a.google.com with SMTP id u186so132931079ita.0 for <spud@ietf.org>; Tue, 26 Jul 2016 20:05:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Cn8+VRHXVmEeuNWgSWAwwYWF+ONcMUZ7GqeNYLSKV5M=; b=QaEVV0rsaxA9ID/Qg/pn9d40HsP8sx9XUyZHeTj5yoUqwTcohuQs8cUDkGyRe6+sfz Ky+eMRvrihXxycylwyIvHikho4QwQEfns2r1WiKegphQMmO/KuduYLhrwfDdrhdZapYt z9c2BVc2VxUMhknT6RXU/vx/gVyHGTNbE/TkeMDzNO6XFJo7JyfxPAcs+gSSV+BTMMQp PYjEft020hw9Au9rBQL9eBem0d008EDY9EvANYQGs1I3Y0+Bdb/+a9/TZ9Z7ntP6ASZC q9e6LiJj6GvysGNvJ8ws3vmne5KrWXTxGmJ5j8EKq5BLGFO1ulaGrAyUKNmoOXl69dAg piig==
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:from:date :message-id:subject:to:cc; bh=Cn8+VRHXVmEeuNWgSWAwwYWF+ONcMUZ7GqeNYLSKV5M=; b=IiIQC/i4AL+eR9z6EcECzjxT10NXIEfqN9MpTrb42C9he+5aeRzP1JKIrJ2VZCk8fu 97piwjZct4MVNZ+Ui8jcPlLY7YUAMCVOW0ktfvuN9gUP3fzUVKMzhDFjYy4COL/7+7MS QF6KCZ6gKycB1C8e0hyXYJsFZQ0VY9xXQ2eJlIclOWzWIuKV8kO+5TQHjZ+f5moHumgh 6qjlRpvJlUXxg3PQD2TFCgKrus2rPz/jmE020UN1/jG5yid/YV5K6Z0iUCpWtk7zwNzJ Uq+MR1dPpy0+AfFwRqNMlFXvd0ETYf5fQVgKKk+sz8XITwOmp6w+iChIekN35dHBDh2b tj8w==
X-Gm-Message-State: AEkoout7dtAvCNIFXABOBjstiJdUdyAGNLia1KM314/+cQVH3JLSI2xQ9+wHczX2IrG6i6crRaGxa7s/uRdV7w==
X-Received: by 10.36.14.193 with SMTP id 184mr31445979ite.91.1469588701671; Tue, 26 Jul 2016 20:05:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.21.130 with HTTP; Tue, 26 Jul 2016 20:05:00 -0700 (PDT)
In-Reply-To: <A4BAAB326B17CE40B45830B745F70F10EE3B01C3@VOEXM17W.internal.vodafone.com>
References: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> <alpine.DEB.2.02.1607211643150.2309@uplift.swm.pp.se> <0f504f66-1df8-e2da-b55a-3e44e67d0912@tele.no> <alpine.DEB.2.02.1607211712500.2309@uplift.swm.pp.se> <3F114FAB-6F70-4908-939C-1DA5661B2113@netapp.com> <alpine.DEB.2.02.1607211724010.2309@uplift.swm.pp.se> <FD62252A-85F2-49A6-ADBF-4F85E9357182@netapp.com> <A4BAAB326B17CE40B45830B745F70F10EE3B01C3@VOEXM17W.internal.vodafone.com>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 26 Jul 2016 20:05:00 -0700
Message-ID: <CALx6S36qGMwaYeE1_2GYnd3sKn1PzBDRtdkcEZN8cmTEJ7BAOA@mail.gmail.com>
To: "Smith, Kevin, (R&D) Vodafone Group" <Kevin.Smith@vodafone.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/q5qsv6jy_eILRWszNyDNUbU7BYk>
Cc: Frode Kileng <frodek@tele.no>, "spud@ietf.org" <spud@ietf.org>, "Eggert, Lars" <lars@netapp.com>, Mikael Abrahamsson <swmike@swm.pp.se>
Subject: Re: [Spud] No. Operators don't need SPUD for mobile network management
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 27 Jul 2016 03:05:04 -0000

On Mon, Jul 25, 2016 at 3:49 AM, Smith, Kevin, (R&D) Vodafone Group
<Kevin.Smith@vodafone.com> wrote:
> Another operator here:  I like the notion of PLUS being used to hint to the TCP sender regarding network radio cell conditions, i.e. mobile throughput guidance[1].  So network information being sent out to help tune cwnd.
>
I am not a big fan of having middleboxes purposely parsing an
modifying TCP options, but I do like security considerations of mobile
guidance and hope that PLUS might adopt some of the same concepts.
Specifically:

"The protocol specified in this document assumes that a trustful
relationship between the Throughput Guidance Provider and the TCP
server has been formed"

and

"Throughput guidance is considered confidential information"

and

"The identity of the Mobile Throughput Guidance provider that injects
the throughput guidance header must be explicitly known to the
endpoint receiving the information."

Tom

v2.23.0 | Report a Bug | By Email