Subject: [Marnew] Why?

From: Ca By <[email-masked]>
Date: Thu, 18 Jun 2015 05:57:11 -0700

hi folks,

Mobile network operator here

Is there a summary of why mobile networks are special and require treatment
that is above and beyond dsl / cable / enterprise networks?

I understand spectrum is precious, but so is copper and fiber plants.

I read the gsma document, but i found it to be unhelpful

Regards,
CB

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Thu, 18 Jun 2015 13:15:20 +0000

This would be an interesting topic for a submission...

Mobile/terse. DYAC. 

> On Jun 18, 2015, at 2:57 PM, Ca By <[email-masked]> wrote:
> 
> hi folks,
> 
> Is there a summary of why mobile networks are special and require treatment that is above and beyond dsl / cable / enterprise networks?
> 
> _______________________________________________
> Marnew mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/marnew

---

From: "Smith, Kevin, (R&D) Vodafone Group" <[email-masked]>
Date: Thu, 18 Jun 2015 13:27:20 +0000

Hi CB,

> Is there a summary of why mobile networks are special and require treatment that is above and beyond dsl / cable / enterprise networks?
You’re right, this needs to be more explicit. All are regulated networks (mobile/DSL/cable by licencing authority(s), enterprise by company), so for me the key distinction for mobile is radio signal volatility and rapid ingress/egress to the network. The resulting increased packet loss and cell congestion bursts arguably make queue management more important in radio: i.e. queuing the content by type so that it can be delivered according to latency/bandwidth requirements. The content type is harder (or not possible) to infer when encrypted. Would be good to know to what extent this is also a problem in  DSL/cable.

> I understand spectrum is precious, but so is copper and fiber plants.
Agreed, I don’t think that is a valid reason to distinguish mobile.

> I read the gsma document, but i found it to be unhelpful
This document was the basis for [1]: happy to take comments/issues at [2].

[1] http://tools.ietf.org/html/draft-smith-encrypted-traffic-management-02
[2] https://github.com/Kevsy/encrypted-traffic-management

Cheers
Kevin

Kevin Smith, Vodafone R&D

---

From: Roland Zink <[email-masked]>
Date: Thu, 18 Jun 2015 15:28:05 +0200

> I understand spectrum is precious, but so is copper and fiber plants.
The difference here is that you can produce more copper and fiber to 
increase capacity, but you can't produce more spectrum. Another 
difference may be that mobile devices usually run from battery. Saving 
network interactions saves energy. Btw. I'm not working for a mobile 
network operator.
> I read the gsma document, but i found it to be unhelpful
Regards,
Roland

---

From: 🔓Dan Wing <[email-masked]>
Date: Thu, 18 Jun 2015 10:52:50 -0700

On 18-Jun-2015 06:27 am, Smith, Kevin, (R&D) Vodafone Group <[email-masked]> wrote: 
> You’re right, this needs to be more explicit. All are regulated networks (mobile/DSL/cable by licencing authority(s), enterprise by company), so for me the key distinction for mobile is radio signal volatility

Does WiFi suffer the same radio issues?

> and rapid ingress/egress to the network.

I don't understand what is meant by rapid ingress/egress to the network.

> The resulting increased packet loss and cell congestion bursts arguably make queue management more important in radio: i.e. queuing the content by type so that it can be delivered according to latency/bandwidth requirements. The content type is harder (or not possible) to infer when encrypted. Would be good to know to what extent this is also a problem in  DSL/cable.
>  
> [1] http://tools.ietf.org/html/draft-smith-encrypted-traffic-management-02 <http://tools.ietf.org/html/draft-smith-encrypted-traffic-management-02>
> [2] https://github.com/Kevsy/encrypted-traffic-management <https://github.com/Kevsy/encrypted-traffic-management>
Nice summary document, thanks.  I don't think I had read it previously, my bad.

-d

---

From: "Smith, Kevin, (R&D) Vodafone Group" <[email-masked]>
Date: Fri, 19 Jun 2015 15:54:05 +0000

Hi Dan, 

> Does WiFi suffer the same radio issues?

I assume so, would be good to hear from experts on similarities/differences. 

> rapid ingress/egress to the network.

Lots of devices entering or leaving a particular access node suddenly. Classic examples would be everyone turning on their phone when landing at an airport, a fast train transiting between two cell towers and the passenger's devices handing over between those towers.

Cheers
Kevin

From: 🔓Dan Wing [mailto:[email-masked]] 
Sent: 18 June 2015 18:53
To: Smith, Kevin, (R&D) Vodafone Group
Cc: Ca By; [email-masked]
Subject: Re: [Marnew] Why?

 

-d

Cheers
Kevin

---

From: Ca By <[email-masked]>
Date: Fri, 19 Jun 2015 09:00:35 -0700

On Fri, Jun 19, 2015 at 8:54 AM, Smith, Kevin, (R&D) Vodafone Group <
[email-masked]> wrote:

> Lots of devices entering or leaving a particular access node suddenly.
> Classic examples would be everyone turning on their phone when landing at
> an airport, a fast train transiting between two cell towers and the
> passenger's devices handing over between those towers.
>
> Cheers
> Kevin
>
>
This a classic corner case that does not happen in real life.

We have been through deep analysis on this when we got scared of what X2
would mean in LTE.

CB

> > Is there a summary of why mobile networks are special and require
> treatment that is above and beyond dsl / cable / enterprise networks?
> You’re right, this needs to be more explicit. All are regulated networks
> (mobile/DSL/cable by licencing authority(s), enterprise by company), so for
> me the key distinction for mobile is radio signal volatility
>
> The resulting increased packet loss and cell congestion bursts arguably
> make queue management more important in radio: i.e. queuing the content by
> type so that it can be delivered according to latency/bandwidth
> requirements. The content type is harder (or not possible) to infer when
> encrypted. Would be good to know to what extent this is also a problem in
>  DSL/cable.
>