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

Toerless Eckert <eckert@cisco.com> Thu, 21 July 2016 13:36 UTC

Return-Path: <eckert@cisco.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 0D19E12D0F0 for <spud@ietfa.amsl.com>; Thu, 21 Jul 2016 06:36:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Level:
X-Spam-Status: No, score=-15.808 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 lqce07zCLU9Z for <spud@ietfa.amsl.com>; Thu, 21 Jul 2016 06:36:05 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B56512D5CD for <spud@ietf.org>; Thu, 21 Jul 2016 06:36:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1654; q=dns/txt; s=iport; t=1469108165; x=1470317765; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=gfw7BpV6l+YfPgIoESfznhQq/b9M2JWPrRGFNNIhfU8=; b=BNbBvAHd0zF7DE8RTdcBdVukMStkLNqnwRXUkmELylvxrV6RF1aK7oJb ZSirj7LaQ0bDlCgKfAPouU4Jv0PeDjtAjf8ro0c3cYNWhgo+sOBxesGK2 GEif4Vp9fzim4fOT9HdQtLKG2vzvyVaMk7+KsaganJZGUCh7Efdf+ikFB 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AlAgBjzpBX/5xdJa1dgz9WfLhmgXsihXgCgS04FAEBAQEBAQFlJ4RdAQUBATg0CxALGAklDwUTNhOIMA69DwEBAQEBAQEBAQEBAQEBAQEBAQEBARcFineBSohRBY8BiiWOYQqBbIRZiHWQIR42ggscgWwcModOAQEB
X-IronPort-AV: E=Sophos;i="5.28,399,1464652800"; d="scan'208";a="299908116"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jul 2016 13:36:04 +0000
Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u6LDa3KX007849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2016 13:36:03 GMT
Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u6LDa25b002882; Thu, 21 Jul 2016 06:36:02 -0700
Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u6LDa2an002880; Thu, 21 Jul 2016 06:36:02 -0700
Date: Thu, 21 Jul 2016 06:36:02 -0700
From: Toerless Eckert <eckert@cisco.com>
To: Frode Kileng <frodek@tele.no>
Message-ID: <20160721133602.GY7377@cisco.com>
References: <43a39476-9327-87ef-204c-d7c614a80669@tele.no>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <43a39476-9327-87ef-204c-d7c614a80669@tele.no>
User-Agent: Mutt/1.4.2.2i
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/5som_SfqNombg9vH6k8Kz-0Lj5Y>
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 13:36:10 -0000

I haven;t talked much with mobile network operators. One data
point a US mobile operator gave me was about recognizing certain 
type p2p traffic that had real bad congestion control and was
monopolizing congested links. And then counter that. I am not sure
if this policing happened on some mobile link/path-segment or at
the edge to the non-mobile core.

Cheers
    Toerless

On Thu, Jul 21, 2016 at 02:40:12PM +0200, Frode Kileng wrote:
> Hi,
> 
> the claims that encryption has taken away something that was used for 
> mobile network traffic management and that PLUS is needed to to save 
> mobile network operations keeps surfacing, including at the BoF today. 
> This view should not be interpreted as representing the view of all 
> mobile operators
> 
> 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.
> 
> Feel free to disagree but then please provide details.
> 
> That said, PLUS may be an enabler for mobile network management 
> practices, for example a 1-bit latency/throughput prioritization indicator.
> 
> Best regards
> Frode Kileng
> 
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud

-- 
---
Toerless Eckert, eckert@cisco.com