Re: [Marnew] MaRNEW Next Steps Updates

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Dirk,

This is a nice write-up of issues. On one point ...

On Tue, Nov 17, 2015 at 11: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.
>
> 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).
>
> 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.


I spent a couple of years at a startup playing with TCP optimization, and
I'm still having a hard time understanding how this works if intermediate
devices aren't ACKing packets themselves, so that receiving an ACK tells
you nothing about what the other end has seen.

Is there any (nonproprietary, if you're under NDA) way around that, or do I
just need to get out more?

Thanks,

Spencer


> 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
>