IETF Logo Mail Archive

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

"Eggert, Lars" <lars@netapp.com> Thu, 21 July 2016 15:23 UTC

Return-Path: <lars@netapp.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 84FC512D74C for <spud@ietfa.amsl.com>; Thu, 21 Jul 2016 08:23:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.208
X-Spam-Level:
X-Spam-Status: No, score=-8.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 n60EjZ7k-aGx for <spud@ietfa.amsl.com>; Thu, 21 Jul 2016 08:23:22 -0700 (PDT)
Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEDFB12D5F7 for <spud@ietf.org>; Thu, 21 Jul 2016 08:23:22 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.28,399,1464678000"; d="asc'?scan'208";a="125044385"
Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx142-out.netapp.com with ESMTP; 21 Jul 2016 08:22:22 -0700
Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 21 Jul 2016 08:22:20 -0700
Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::2c76:6bc2:2216:a24d%21]) with mapi id 15.00.1210.000; Thu, 21 Jul 2016 08:22:21 -0700
From: "Eggert, Lars" <lars@netapp.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Thread-Topic: [Spud] No. Operators don't need SPUD for mobile network management
Thread-Index: AQHR417WpScLTP95BEiIterukq9w8KAjcM8AgAADS4CAAAHWAA==
Date: Thu, 21 Jul 2016 15:22:20 +0000
Message-ID: <3F114FAB-6F70-4908-939C-1DA5661B2113@netapp.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>
In-Reply-To: <alpine.DEB.2.02.1607211712500.2309@uplift.swm.pp.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3124)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.120.60.37]
Content-Type: multipart/signed; boundary="Apple-Mail=_F42E86B2-397D-4E3E-8EE1-E0376ED92F32"; protocol="application/pgp-signature"; micalg="pgp-sha256"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/IDMqYNm2VYXrkr7yYnLTvrTGh58>
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: Thu, 21 Jul 2016 15:23:28 -0000

On 2016-07-21, at 17:15, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> If SPUD comes with flags that say "this is a connection establishment packet" (SYN-like) and another flag that matches ACK, then middle boxes can track connection establishment for all traffic based on SPUD, without needing to know anything more about the traffic. This is the functionality I'm talking about.

I think Christian said much the same thing in an earlier email:

Why is the first packet arriving at a middlebox for which it has no binding not treated as such a "connection establishment packet"? Why does a bit need to be set for it to be treated as such?

Lars

v2.23.0 | Report a Bug | By Email