Subject: [Marnew] MaRNEW Next Steps Updates

From: Natasha Rooney <[email-masked]>
Date: Tue, 10 Nov 2015 06:31:43 +0000

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-guidance/
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 | [email-masked]<mailto:[email-masked]> | +44 (0) 7730 219 765 | @thisNatasha | Skype: [email-masked]<mailto:[email-masked]>
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.

---

From: Dirk Kutscher <[email-masked]>
Date: Tue, 10 Nov 2015 06:59:44 +0000

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:[email-masked]] On Behalf Of Natasha Rooney
Sent: Dienstag, 10. November 2015 07:32
To: [email-masked]
Subject: [Marnew] MaRNEW Next Steps Updates

Hi all!

Caching

Collaborative Frameworks

Keyless SSL

Better Collaboration

Other Ideas

Thank-you all!

Natasha

---

From: Natasha Rooney <[email-masked]>
Date: Wed, 11 Nov 2015 06:46:51 +0000

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

On Nov 10, 2015, at 3:59 PM, Dirk Kutscher <[email-masked]<mailto:[email-masked]>> wrote:

Hi Natasha,

thanks for the update.

Cheers,
Dirk

From: Marnew [mailto:[email-masked]] On Behalf Of Natasha Rooney
Sent: Dienstag, 10. November 2015 07:32
To: [email-masked]<mailto:[email-masked]>
Subject: [Marnew] MaRNEW Next Steps Updates

Hi all!

Caching

Collaborative Frameworks

Keyless SSL

Better Collaboration

Other Ideas

Thank-you all!

Natasha

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Nov 2015 07:18:08 +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.

S.

On 11/11/15 06:46, Natasha Rooney wrote:
> This body part will be downloaded on demand.
>

---

From: "Smith, Kevin, (R&D) Vodafone Group" <[email-masked]>
Date: Wed, 11 Nov 2015 09:29:54 +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:[email-masked]] On Behalf Of Stephen Farrell
Sent: 11 November 2015 07:18
To: Natasha Rooney; Dirk Kutscher
Cc: [email-masked]; 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:
> • UDP Rate Limiting by Mobile Operators • ECN deployments • Middlebox 
> traversal • Packet Traces • speed • rate • What works, and what 
> breaks?
> Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | 
> [email-masked]<mailto:[email-masked]> | +44 (0) 7730 219 765 | 
> @thisNatasha | Skype: [email-masked]<mailto:[email-masked]>
> Tokyo, Japan
> 
> 
> 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.
> 
> 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.
> 
> Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | 
> [email-masked]<mailto:[email-masked]> | +44 (0) 7730 219 765 | 
> @thisNatasha | Skype: [email-masked]<mailto:[email-masked]>
> Tokyo, Japan
> 
> 

_______________________________________________
Marnew mailing list
[email-masked]
https://www.iab.org/mailman/listinfo/marnew

---

From: Dirk Kutscher <[email-masked]>
Date: Tue, 17 Nov 2015 17:48:52 +0000

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.

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:[email-masked]] 
Sent: Mittwoch, 11. November 2015 10:30
To: Stephen Farrell; Natasha Rooney; Dirk Kutscher
Cc: [email-masked]; PEDRO FLOREZ MIÑAMBRES
Subject: RE: [Marnew] MaRNEW Next Steps Updates

Kevin

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

S.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 17 Nov 2015 12:12:47 -0600

Hi, Dirk,

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

On Tue, Nov 17, 2015 at 11:48 AM, Dirk Kutscher <[email-masked]>
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 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).
>
> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> > 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.
>
> 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
>
>
> 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.
>
> > 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
> > 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
> >
> >
> > 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:
> >
> >
> > 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.
> >
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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:
> >
> >
> > 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
> >
> >
> > 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.
> >
> >
> >

---

From: Ca By <[email-masked]>
Date: Tue, 17 Nov 2015 12:33:04 -0800

> 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

> 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

---

From: Dirk Kutscher <[email-masked]>
Date: Wed, 18 Nov 2015 16:49:56 +0000

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?

Hi Spencer,

not talking about any product, but yes, techniques like this come to mind (with the problems you mentioned).

Best regards,
Dirk

Thanks,

Spencer

Best regards,
Dirk

-----Original Message-----
From: Smith, Kevin, (R&D) Vodafone Group [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Mittwoch, 11. November 2015 10:30
To: Stephen Farrell; Natasha Rooney; Dirk Kutscher
Cc: [email-masked]<mailto:[email-masked]>; PEDRO FLOREZ MIÑAMBRES
Subject: RE: [Marnew] MaRNEW Next Steps Updates

Kevin

-----Original Message-----
From: Marnew [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Stephen Farrell
Sent: 11 November 2015 07:18
To: Natasha Rooney; Dirk Kutscher
Cc: [email-masked]<mailto:[email-masked]>; PEDRO FLOREZ MIÑAMBRES
Subject: Re: [Marnew] MaRNEW Next Steps Updates

S.

On 11/11/15 06:46, Natasha Rooney wrote:
> [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>> | +44 (0) 7730 219 765<tel:%2B44%20%280%29%207730%20219%20765> |
> @thisNatasha | Skype: [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> Tokyo, Japan
>
>
> On Nov 10, 2015, at 3:59 PM, Dirk Kutscher <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
> Hi Natasha,
>
> thanks for the update.
>
> From: Marnew [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Natasha
> Rooney
> To: [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>> | +44 (0) 7730 219 765<tel:%2B44%20%280%29%207730%20219%20765> |
> @thisNatasha | Skype: [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> 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<tel:%2B44%20207%20356%200600> 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<tel:%2B44%20207%20356%200600> and highlight the error.
>
>
>

_______________________________________________
Marnew mailing list
[email-masked]<mailto:[email-masked]>
https://www.iab.org/mailman/listinfo/marnew
_______________________________________________
Marnew mailing list
[email-masked]<mailto:[email-masked]>
https://www.iab.org/mailman/listinfo/marnew

---

From: Dirk Kutscher <[email-masked]>
Date: Wed, 18 Nov 2015 17:03:31 +0000

Thanks for the pointer – this essentially supports what I said in terms of ubiquitous middlebox deployment. What’s interesting to note is that HTTP/2 and TLS does not preclude classification and differentiation.

But these measurements are black box measurements, i.e., they don’t tell us exactly what is going on and what impact the machinery has.

Yes, one application for classification.

Personally, I like the ConEx congestion accountability concept better, but this one is easier wrt initial deployment.

Best regards,
Dirk

Best regards,
Dirk

-----Original Message-----
From: Smith, Kevin, (R&D) Vodafone Group [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Mittwoch, 11. November 2015 10:30
To: Stephen Farrell; Natasha Rooney; Dirk Kutscher
Cc: [email-masked]<mailto:[email-masked]>; PEDRO FLOREZ MIÑAMBRES
Subject: RE: [Marnew] MaRNEW Next Steps Updates

Kevin

-----Original Message-----
From: Marnew [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Stephen Farrell
Sent: 11 November 2015 07:18
To: Natasha Rooney; Dirk Kutscher
Cc: [email-masked]<mailto:[email-masked]>; PEDRO FLOREZ MIÑAMBRES
Subject: Re: [Marnew] MaRNEW Next Steps Updates

S.