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

Christian Huitema <huitema@microsoft.com> Tue, 26 July 2016 17:46 UTC

Return-Path: <huitema@microsoft.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 553F612D882 for <spud@ietfa.amsl.com>; Tue, 26 Jul 2016 10:46:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Level:
X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 oV6KW3U2SgwK for <spud@ietfa.amsl.com>; Tue, 26 Jul 2016 10:46:23 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0123.outbound.protection.outlook.com [104.47.38.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9F5112D87F for <spud@ietf.org>; Tue, 26 Jul 2016 10:46:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jyntoJmZFJx0SOp8KA9Fiao36Lr8r/XDIyBKDzjZ4N4=; b=KJOZYphBdthGRHXtNXqcsDvTaqIGxV1vMYR4UouVwWc8fn1LNtGc3IxyMyFYRDA9eqsYbmwgRva7cYpXJ7psDfQOGFUAkUxEd94PNjfswGP2R6+yYWGxEjSlH8olNavVlkE0lBKTqr9quD8yOIrM9GSmh9YZSPVYtRTBvaQ+B2Y=
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0654.namprd03.prod.outlook.com (10.160.96.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Tue, 26 Jul 2016 17:46:17 +0000
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0549.016; Tue, 26 Jul 2016 17:46:17 +0000
From: Christian Huitema <huitema@microsoft.com>
To: "Smith, Kevin, (R&D) Vodafone Group" <Kevin.Smith@vodafone.com>, "Eggert, Lars" <lars@netapp.com>, Mikael Abrahamsson <swmike@swm.pp.se>
Thread-Topic: [Spud] No. Operators don't need SPUD for mobile network management
Thread-Index: AQHR417XM+OLp574lU2NA11SMaga06Ai+3YAgAADS4CAAAHZAIAAAWYAgAABnYCABfoTAIACBBtg
Date: Tue, 26 Jul 2016 17:46:17 +0000
Message-ID: <DM2PR0301MB065544AC23473D817B1ADDB0A80E0@DM2PR0301MB0655.namprd03.prod.outlook.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>
In-Reply-To: <A4BAAB326B17CE40B45830B745F70F10EE3B01C3@VOEXM17W.internal.vodafone.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com;
x-originating-ip: [2001:4898:80e8:2::14d]
x-ms-office365-filtering-correlation-id: 34c9559c-19a4-406c-5cca-08d3b57cbf41
x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0654; 6:QrevvIHvi3FlJcFkFFaC0GasRLXA8HdNsWsCNlBGkPLTg2Got41N7jDUMPaU5Ku0CGOMnxHzoDMBoLy7mpblWlceH90PfRbKLQZTStIpaelPoq1x5wF9jR6zIXTog2SSfnQFhiRQ+m0QzcBo+gTpLlP1k/YBwDcg3XagB98FOaLrNzq1UviAGcZm4ff7Pqe5i+4KgBZbfq1z5Xtpq7w/kJ8C1WCAVJIN0BU8yRIbSQ3im+KERzX/5R6uuyYGzFccY3zRKV2HYOYojtMuWVEwFgxv92g9fM0IxvtuCjxIaIBIZw3BCVcCx7rICtJw6YqwCVuNF1ASoRTbdQlvDvJVbQ==; 5:yxln3G7+Ii2Ber9XFPciwfOTj01t2flgD78W/kY1KMsFm19Unpi0MX8kpQRb1MyKby6WetMjSGHVNgq3zFV+P+48GnXOARPY0TbZwt4BO8jE1nLtRC45aowl8CGWhI28RSM+WA3JMiNQHGBTLDq1sQ==; 24:kjCHbgb/Wi+hjyccWAaUiofCDno7wNKGjZSXVd04r1wekxnZJSXVWrgswcgQPi/8ukpYsBzUEXM1Fef7GFQ2SS9JP0oMcn3QEwqqzoOeLdI=; 7:4FNI6qh3sXnRk9W4stXHNP4Vrl7bgNYY7Opx+olI28ucWOb4/+JErMSKhaDbbRicIrhmtnaFyEBFkI4jN7FgNIdvA4FUYjBTwBJcl5k0UlHF4ZAW0OWl30pCJ5qjN1xL5WzfvnsC5UXhzXskFardKRSX+FECOJMnd6BUdJqAYxgusZ8SZYEKXBO582NTaltgwyap4RHeolSwjdve6+/q3pCPbxSt8oWdjXq0e8xg1VujbfzU1JPEgwpWYTLE/4TJ
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0654;
x-microsoft-antispam-prvs: <DM2PR0301MB0654D58DB76E52F4E0798F18A80E0@DM2PR0301MB0654.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0654; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0654;
x-forefront-prvs: 00159D1518
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(24454002)(189002)(377454003)(8936002)(81156014)(33656002)(81166006)(10400500002)(5005710100001)(10290500002)(8990500004)(5002640100001)(8666005)(189998001)(10090500001)(11100500001)(92566002)(68736007)(9686002)(586003)(6116002)(102836003)(93886004)(106116001)(2906002)(4326007)(105586002)(106356001)(87936001)(3280700002)(101416001)(2900100001)(74316002)(86612001)(2950100001)(5003600100003)(7696003)(7736002)(122556002)(3660700001)(7846002)(5001770100001)(97736004)(305945005)(76576001)(99286002)(86362001)(54356999)(50986999)(77096005)(76176999)(7059030)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0654; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2016 17:46:17.7314 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0654
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/0D3yKK1SaAUhIXDnXtfTwS3bUqQ>
Cc: Frode Kileng <frodek@tele.no>, "spud@ietf.org" <spud@ietf.org>
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: Tue, 26 Jul 2016 17:46:25 -0000

On Monday, July 25, 2016 3:49 AM, Kevin Smith 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.

Isn't that already available from the modem?

> For sender to network: If there are ways to safely indicate open/close, 'drop
> me/queue me when I hit congestion', and 'I am a retransmitted packet' then
> that would be of interest too. But I fully respect the privacy concerns that were
> raised at the BoF, and would be happy to see a limited scope accordingly.

We are most likely to get consensus on simple issues like DDOS prevention and NAT traversal. The endpoints cannot really fight DDOS all by themselves, the damage is already done by the time the packets reach them, so this is certainly an area where there is a desire to collaborate. Currently the endpoints keep sending "keep alive" traffic every 15 to 30 seconds to maintain the state in the NAT and firewalls; finding something better would be nice.

-- Christian Huitema