Re: [Marnew] MaRNEW Next Steps Updates

"Smith, Kevin, (R&D) Vodafone Group" <Kevin.Smith@vodafone.com> Wed, 11 November 2015 09:30 UTC

Return-Path: <Kevin.Smith@vodafone.com>
X-Original-To: marnew@ietfa.amsl.com
Delivered-To: marnew@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836381B48C6 for <marnew@ietfa.amsl.com>; Wed, 11 Nov 2015 01:30:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
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 azqKv_SYm9nh for <marnew@ietfa.amsl.com>; Wed, 11 Nov 2015 01:30:01 -0800 (PST)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.147]) (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 085861B48C1 for <marnew@iab.org>; Wed, 11 Nov 2015 01:29:59 -0800 (PST)
Received: from [85.158.139.163] by server-11.bemta-5.messagelabs.com id 8C/42-24494-59A03465; Wed, 11 Nov 2015 09:29:57 +0000
X-Env-Sender: Kevin.Smith@vodafone.com
X-Msg-Ref: server-8.tower-188.messagelabs.com!1447234197!721084!1
X-Originating-IP: [195.232.244.133]
X-StarScan-Received:
X-StarScan-Version: 7.19.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12395 invoked from network); 11 Nov 2015 09:29:57 -0000
Received: from mailout01.vodafone.com (HELO mailout01.vodafone.com) (195.232.244.133) by server-8.tower-188.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Nov 2015 09:29:57 -0000
Received: from mailint04.vodafone.com (mailint04.vodafone.com [195.232.244.201]) by mailout01.vodafone.com (Postfix) with ESMTP id 3nwgkr5Zckz1yBq; Wed, 11 Nov 2015 10:29:56 +0100 (CET)
Received: from mailint04.vodafone.com (localhost [127.0.0.1]) by mailint04.vodafone.com (Postfix) with ESMTP id 3nwgkr3mwrzfZQP; Wed, 11 Nov 2015 10:29:56 +0100 (CET)
Received: from VOEXC02W.internal.vodafone.com (voexc02w.dc-ratingen.de [145.230.101.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint04.vodafone.com (Postfix) with ESMTPS id 3nwgkr3LzczfZJJ; Wed, 11 Nov 2015 10:29:56 +0100 (CET)
Received: from VOEXC30W.internal.vodafone.com (145.230.103.202) by VOEXC02W.internal.vodafone.com (145.230.101.22) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 11 Nov 2015 10:29:56 +0100
Received: from VOEXM17W.internal.vodafone.com ([169.254.1.209]) by voexc30w ([145.230.103.202]) with mapi id 14.03.0224.002; Wed, 11 Nov 2015 10:29:55 +0100
From: "Smith, Kevin, (R&D) Vodafone Group" <Kevin.Smith@vodafone.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Natasha Rooney <nrooney@gsma.com>, Dirk Kutscher <Dirk.Kutscher@neclab.eu>
Thread-Topic: [Marnew] MaRNEW Next Steps Updates
Thread-Index: AQHRG4F34n6LF8ZxP066EAU0Fsq7op6U0ioQgAF/jICAAAi+AIAAMUlQ
Date: Wed, 11 Nov 2015 09:29:54 +0000
Message-ID: <A4BAAB326B17CE40B45830B745F70F10AC8BD79F@VOEXM17W.internal.vodafone.com>
References: <5DC0EBDD-D066-4951-8448-4213D52A4A7C@gsma.com> <82AB329A76E2484D934BBCA77E9F5249A676183B@PALLENE.office.hd> <E08EDA77-1907-4A08-8AE3-B20825FBF291@gsma.com> <5642EBB0.8030509@cs.tcd.ie>
In-Reply-To: <5642EBB0.8030509@cs.tcd.ie>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/marnew/sjtXoXriWpSGBovCbb_8c9NatI0>
Cc: "marnew@iab.org" <marnew@iab.org>, PEDRO FLOREZ MIÑAMBRES <pedro.florezminambres@telefonica.com>
Subject: Re: [Marnew] MaRNEW Next Steps Updates
X-BeenThere: marnew@iab.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Managing Radio Networks in an Encrypted World <marnew.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/marnew>, <mailto:marnew-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/marnew/>
List-Post: <mailto:marnew@iab.org>
List-Help: <mailto:marnew-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/marnew>, <mailto:marnew-request@iab.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Nov 2015 09:30:04 -0000

> I think Jana asked a good question (a few times:-), which is "what happens when you take out all the middlebox stuff?"
> That would need translation into specific with/without configurations, but I think would be a valuable thing to try to measure in a reproducible fashion.

+1, we can look to test that. 

Regarding metrics, a diff packet_in packet_out for each hop within the network seems useful, as does the impact on latency and throughput within the core network. That should be a good starting point; the we can look at the impact across the radio cell for multiple connections. Any other ideas for metrics?

Kevin


-----Original Message-----
From: Marnew [mailto:marnew-bounces@iab.org] On Behalf Of Stephen Farrell
Sent: 11 November 2015 07:18
To: Natasha Rooney; Dirk Kutscher
Cc: marnew@iab.org; PEDRO FLOREZ MIÑAMBRES
Subject: Re: [Marnew] MaRNEW Next Steps Updates


I think Jana asked a good question (a few times:-), which is "what happens when you take out all the middlebox stuff?"
That would need translation into specific with/without configurations, but I think would be a valuable thing to try to measure in a reproducible fashion.

S.

On 11/11/15 06:46, Natasha Rooney wrote:
> Hey Dirk!
> 
> I am putting together a list now - but am still in the early phases. I have a bunch of research to go through, as well as taking some inspiration from the paper Pedro presented in HOPs. So far the list looks a little like this, but I am desperately seeking more input to this and will add to it once I get through the papers!
> 
> • Packet flow on the RRC
> • Mobile operator use of TCP Options
> • UDP Rate Limiting by Mobile Operators • ECN deployments • Middlebox 
> traversal • Packet Traces • speed • rate • What works, and what 
> breaks?
> • What breakages are intentional. E.g. where is UDP blocked?
> • General Network Statistics
> • Bandwidth
> • Latency
> 
> If you have anything to add please do let me know! Also let me know if you want to be more involved in this and we can chat sometime!
> 
> Natasha
> 
> 
> Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | 
> nrooney@gsma.com<mailto:nrooney@gsma.com> | +44 (0) 7730 219 765 | 
> @thisNatasha | Skype: nrooney@gsm.org<mailto:nrooney@gsm.org>
> Tokyo, Japan
> 
> 
> On Nov 10, 2015, at 3:59 PM, Dirk Kutscher <Dirk.Kutscher@neclab.eu<mailto:Dirk.Kutscher@neclab.eu>> wrote:
> 
> Hi Natasha,
> 
> thanks for the update.
> 
> Regarding metrics, is there a more concrete idea of what exactly we want to measure (and how that would help)?
> 
> Cheers,
> Dirk
> 
> From: Marnew [mailto:marnew-bounces@iab.org] On Behalf Of Natasha 
> Rooney
> Sent: Dienstag, 10. November 2015 07:32
> To: marnew@iab.org<mailto:marnew@iab.org>
> Subject: [Marnew] MaRNEW Next Steps Updates
> 
> Hi all!
> 
> I hope those of you who attended IETF94 had a great trip and those of you who stayed at home had a more relaxing week! I have some updates for you with regards to the Next Steps for MaRNEW.
> 
> A small group of Technical Programme Committee members and some guests met at IETF94 to discuss the next steps for some of the key identified items to develop at the MaRNEW Workshop. Below is that list of main items which we will follow up, and the next steps for each:
> 
> 
> Metrics and metric standards
> As we all know HOPs is collecting statistics to help with the evolution of the stack programme. The best course of action here is to provide data into HOPs. I know for many telecommunication companies and mobile operators that this is near impossible for competition reasons (and for those who do not work in telecomms please be assured that everyone on this list understands the need for stats, so they are not the blocker, the blockers are other internal teams and even higher management). Therefore I am going to investigate setting up a programme within GSMA to collect and anonymise data, and possibly work on some standards for this too (to bring to the IETF). Over the next few weeks I will put this plan together with help from others, and present it to the internal teams at GSMA. If you don’t like this idea please do let me know - I am happy to take advice!
> 
> tl;dr: Natasha to work on developing a data collection programme at GSMA, will work with Kevin on this. Brian and Casey (from Caida) will provide some input. Natasha will give updates on this in early January. Data will go into HOPs.
> 
> 
> Evolving TCP or the Transport Layer
> These topics seem to be the perfect suggestion to bring to BOF or BarBOF at IETF95. This could include topics / drafts such as cooperative frameworks, SPUD, TCP option based drafts, TCP evolutions drafts. I will talk to Ted about setting some mailing list up for this to get this rolling. I should also speak to the stack evolution programme about this too.
> 
> tl;dr: There will most likely be a BOF or BarBOF in IETF95 to continue working on this topic.
> 
> 
> Mobile Throughput Guidance
> https://datatracker.ietf.org/doc/draft-flinck-mobile-throughput-guidan
> ce/ There was some renewed interest in the MTG draft at MaRNEW. The 
> authors are working on gathering data on the performance of MTG to add to the draft and bring to the IETF soon. The authors will try to bring it to the IETF95 BOF / BarBOF we will plan, but there is no guarantee of this yet.
> 
> tl;dr: Data will be added to the draft, new draft version will likely be ready by IETF95.
> 
> 
> Zero / One bit for latency bandwidth tradeoff A reminder for all: this 
> idea looks at removing all network management tools from a network, test, then add one bit for latency / bandwidth tradeoff (e.g. video or not video, or latency or bandwidth, drop vs queue) and test again to see if there is an improvement. Possible expand to other bits, and then find the optimum combination taking privacy into account. The group agreed that testing this is necessary, and this work is perfect fit for university or lab based study. I will investigate bringing it into the GSMA proposal, but it probably it a better fit to fund some university research on this outside of the GSMA and IETF work existing.
> 
> ACTION (ALL): I will start investigating this in January. If you have some ideas of how we could fund / find a research body to work on this let me know.
> 
> 
> Caching
> Here we are mostly referring to the Blind Caching idea given in a draft proposal (https://github.com/EricssonResearch/blind-cache-draft/blob/master/draft-eriksson-oob-cache-latest.txt). We decided to leave this to the authors of the draft and await for them to bring this to the IETF.
> 
> tl;dr: Blind Caching may be brought to IETF95/6 by the draft authors.
> 
> 
> Collaborative Frameworks
> This idea is to do with either sending data up or down for network management benefits, and is closely related to the Transport Evolution idea. Given this link is makes sense to bring any idea here (SPUD and MTG included) to the proposed BOF / BarBOF in 95.
> 
> tl;dr: There will most likely be a BOF or BarBOF in IETF95 to continue working on this topic.
> 
> 
> Keyless SSL
> There is some preliminary work going on within the IETF with regards to Keyless SSL. It is likely this will be the subject of a BOF or new work item at IETF95. This group will not do any more work on this - if you are interested in this work I suggest you pay attention to the SAAG mailing list.
> 
> tl;dr: Will be brought to IETF, see updates on SAAG mailing list.
> 
> 
> Better Collaboration
> The mobile operator, OEM and internet communities are working more collaboratively, so we want to continue this. There is no specific actions to take here - just a reminder to keep the conversations and work going!
> 
> 
> Other Ideas
> We did have some other ideas, which are detailed below. We have no concrete plans for these ideas. so if you do have some or want to push these up to a higher priority then please respond to this mail with some way of how we could work on that particular item:
> 
> 
>   *   API for app to query network, or for network to query app
>   *   Heuristics
>   *   Standard approach for operator to offer servicesto Content Providers
>   *   5G Requirements
>   *   Bearers discussion (happening within GSMA)
>   *   CDN improvements
> 
> 
> 
> Thanks all for the help on these items and the general effort for MaRNEW. If you have comments or questions on the above please post them to the list or directly to me (preference is to post to the list).
> 
> Thank-you all!
> 
> Natasha
> 
> 
> Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | 
> nrooney@gsma.com<mailto:nrooney@gsma.com> | +44 (0) 7730 219 765 | 
> @thisNatasha | Skype: nrooney@gsm.org<mailto:nrooney@gsm.org>
> Tokyo, Japan
> 
> 
> This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.
> 
> 
> This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.
> 
> 
> 
> This body part will be downloaded on demand.
> 

_______________________________________________
Marnew mailing list
Marnew@iab.org
https://www.iab.org/mailman/listinfo/marnew