Re: [Marnew] MaRNEW Next Steps Updates

[Ca By <[e-mail]>]

On Tue, Nov 17, 2015 at 9:48 AM, Dirk Kutscher <[e-mail]>
wrote:

> Hi all,
>
> thanks for the replies! (Just made it back home from Japan/California, so
> apologies for the delay in following up...)
>
> It'd be great to be able to obtain measurements results for "with and
> without middlebox support", but I am pretty sure that (for commercial
> mobile networks) this is really difficult/impossible to do, so it may be a
> rhetorical question really. I'd be really happy if someone proved me wrong.
>
>
Please see this methodology and results

https://www3.cs.stonybrook.edu/~phillipa/papers/traffic-diff_imc15.pdf



> I am not so sure a big measurement effort would take us very far,
> especially not knowing what intermediary functions were actually involved
> in such measurements.
>
> I would personally rather follow an analytical and constructive approach,
> i.e., understanding typical set-ups, their motivation and then think about
> what could be improved in a next-generation system (bringing together
> knowledge and requirements from the radio domain & the transport protocol
> and application layer domain).
>
> For example, I think it's no secret that mobile network operators deploy
> transport layer proxies and (often) application layer proxies, including
> caches and transcoding systems. The latter may become less relevant in the
> future because of HTTP/2 (or, CDNs may take over that role).
>
>
Maybe economic traffic shapers ?

https://newsroom.t-mobile.com/media-kits/un-carrier-x.htm



> There is a (at least a perceived) need for TCP optimizers in mobile
> networks -- for splitting TCP congestion control loops and improving
> downstream performance. With the current EPS architecture, there is not
> much flexibility as to where to deploy such proxies -- in most cases you
> would put them close to the PDN tunnel termination point, i.e., the PDN
> gateway. You would also not have too many of those on a path, i.e., one is
> often enough.
>
> Radio resource control on base station and corresponding load and
> performance information may be available through management interfaces.
> This may be leveraged by a traffic management system to control performance
> enhancing proxies.
>
> For analyzing and understanding current operators needs such network
> architecture and deployment descriptions would be great to have (and then
> measurements results could be really useful, too). I acknowledge that
> operators may not always want to disclose such information with a high
> level of detail.
>
> Assuming for a moment that this general description is accurate, thoughts
> about a next-generation system should IMO involve:
>
> - are there options to achieve performance parity with e2e-only transport
> approaches, leveraging capacity sharing technologies such as AQM, ECN and
> responsive transports/applications?
>
> - OR: with the expected set of heterogeneous radio access technologies in
> the future (mmWave, legacy LTE, WiFi, device-to-device etc.),  is there a
> need for localized control loops and how could that be implemented in a
> clean way?
>
> - is there any benefit in sharing current radio resource utilization/cost
> information with such control loops?
>
> - is there any benefit in informing radio links of rudimentary flow
> service requirements (delay-tolerant vs regular best-effort), and what
> existing signaling could be used for that?
>
> These question are at the heart of 5G performance discussions, so I think
> this is where we want to contribute (i.e,. to a better system design).
>
> The above all relates to the relatively-short term solution time frame.
>
> For the mid-/long term I'd say it's fair to say that we know TCP cannot be
> perfect in networks with very heterogeneous local link layers and
> corresponding delay / loss properties. There are also real pain points in
> doing multipath communication in the presents of CDN and DNS redirection.
> It does not seem to scale to require operators to run individual CDN boxes
> for each individual CDN operator and application service provider. It does
> not seem to scale to extend the current CDN model to edge and deep
> in-network caching, especially not considering the security problems
> (certificate delegation). For non-CDN traffic, TLS implies no caching, so
> we can only choose between security and good performance -- really?
>
> Overcoming these issues requires more drastic changes (and there are ideas
> for that), but perhaps that should be kept separate from the short-term
> discussion.
>
> In general, I think it'd be good to get radio and core network experts in
> the same room as transport and application experts to discuss the
> above-listed questions.
>
> Best regards,
> Dirk
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: Smith, Kevin, (R&D) Vodafone Group [mailto:[e-mail]]
> Sent: Mittwoch, 11. November 2015 10:30
> To: Stephen Farrell; Natasha Rooney; Dirk Kutscher
> Cc: [e-mail]; 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.
>
> +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:[e-mail]] On Behalf Of Stephen Farrell
> Sent: 11 November 2015 07:18
> To: Natasha Rooney; Dirk Kutscher
> Cc: [e-mail]; 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 |
> > [e-mail]<mailto:[e-mail]> | [phone] |
> > @thisNatasha | Skype: [e-mail]<mailto:[e-mail]>
> > Tokyo, Japan
> >
> >
> > On Nov 10, 2015, at 3:59 PM, Dirk Kutscher <[e-mail]
> <mailto:[e-mail]>> 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:[e-mail]] On Behalf Of Natasha
> > Rooney
> > Sent: Dienstag, 10. November 2015 07:32
> > To: [e-mail]<mailto:[e-mail]>
> > 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 |
> > [e-mail]<mailto:[e-mail]> | [phone] |
> > @thisNatasha | Skype: [e-mail]<mailto:[e-mail]>
> > 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 [phone] 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 [phone] and highlight the error.
> >
> >
> >
> > This body part will be downloaded on demand.
> >
>
> _______________________________________________
> Marnew mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/marnew
> _______________________________________________
> Marnew mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/marnew
>