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

Mikael Abrahamsson <swmike@swm.pp.se> Thu, 21 July 2016 14:47 UTC

Return-Path: <swmike@swm.pp.se>
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 0004E12D68F for <spud@ietfa.amsl.com>; Thu, 21 Jul 2016 07:47:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.736
X-Spam-Level:
X-Spam-Status: No, score=-2.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FUZZY_AMBIEN=0.552, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 8Hqtkj4chboe for <spud@ietfa.amsl.com>; Thu, 21 Jul 2016 07:47:40 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0229212D675 for <spud@ietf.org>; Thu, 21 Jul 2016 07:47:40 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 79EA4A2; Thu, 21 Jul 2016 16:47:37 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1469112457; bh=WD5LwRF9RSlojlf9P3KlRJqYcjzXao9NV2PHV7ywbH0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=hzPL9l7fIqdmbbAWyBgRhimbxcyuEdSDzhbP7HgYggsD/sq3kpY6DwCAqULf9rork 359gMxwml3xAz2GQpFBz+dxn0iFZ4p/DjnER3DB52VncfonDeZDL056M1ohPXT8yVa PCMWSFzug9DzsDVqltzX2oJB+t/kXh2wKMVbf/LE=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7014DA1; Thu, 21 Jul 2016 16:47:37 +0200 (CEST)
Date: Thu, 21 Jul 2016 16:47:37 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Frode Kileng <frodek@tele.no>
In-Reply-To: <43a39476-9327-87ef-204c-d7c614a80669@tele.no>
Message-ID: <alpine.DEB.2.02.1607211643150.2309@uplift.swm.pp.se>
References: <43a39476-9327-87ef-204c-d7c614a80669@tele.no>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/OwIaIfHGEn7CyeIB0aspMzKoQwQ>
Cc: 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 14:47:42 -0000

On Thu, 21 Jul 2016, Frode Kileng wrote:

> The rule is that all "Internet traffic" is assigned the default bearer 
> and there's no differentiated handling of the traffic within this 
> bearer. It has been hinted that there's exceptions "somewhere" but as 
> long this claim is never substantiated, and there's no problem related 
> to this in today in mobile networks, we should conclude that PLUS is not 
> solving an existing problem related to mobile network management.

I know people that for instance have middle-boxes that drops unsolicited 
TCP SYN+ACK packets (no SYN was seen, now there is a SYN-ACK that the end 
system didn't seem to have requested).

This saves power for devices and it saves signaling resources in the 
ombile network. I've seen mobile networks melt down because of someone 
else being SYN-flooded with spoofed source addresses and the resulting 
"backscatter" was not doing the mobile network any good.

SPUD could be used to have similar benefits for non-TCP traffic, in that 
it might be easier to identify un-solicited traffic.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se