Subject: [Spud] No. Operators don't need SPUD for mobile network management

From: Frode Kileng <[email-masked]>
Date: Thu, 21 Jul 2016 14:40:12 +0200

Hi,

the claims that encryption has taken away something that was used for 
mobile network traffic management and that PLUS is needed to to save 
mobile network operations keeps surfacing, including at the BoF today. 
This view should not be interpreted as representing the view of all 
mobile operators

The rule is that all "Internet traffic" is assigned the default bearer 
and there's no differentiated handling of the traffic within this 
bearer. It has been hinted that there's exceptions "somewhere" but as 
long this claim is never substantiated, and there's no problem related 
to this in today in mobile networks, we should conclude that PLUS is not 
solving an existing problem related to mobile network management.

Feel free to disagree but then please provide details.

That said, PLUS may be an enabler for mobile network management 
practices, for example a 1-bit latency/throughput prioritization indicator.

Best regards
Frode Kileng

---

From: Natasha Rooney <[email-masked]>
Date: Thu, 21 Jul 2016 13:05:01 +0000

I agree with Frode here - the final sentence was more of what I was trying to get to in today’s BoF.

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

On 21 Jul 2016, at 14:40, Frode Kileng <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

the claims that encryption has taken away something that was used for mobile network traffic management and that PLUS is needed to to save mobile network operations keeps surfacing, including at the BoF today. This view should not be interpreted as representing the view of all mobile operators

The rule is that all "Internet traffic" is assigned the default bearer and there's no differentiated handling of the traffic within this bearer. It has been hinted that there's exceptions "somewhere" but as long this claim is never substantiated, and there's no problem related to this in today in mobile networks, we should conclude that PLUS is not solving an existing problem related to mobile network management.

That said, PLUS may be an enabler for mobile network management practices, for example a 1-bit latency/throughput prioritization indicator.

Best regards
Frode Kileng

_______________________________________________
Spud mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spud

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: Tom Herbert <[email-masked]>
Date: Thu, 21 Jul 2016 15:28:56 +0200

> That said, PLUS may be an enabler for mobile network management practices,
> for example a 1-bit latency/throughput prioritization indicator.
>
Doesn't DSCP/TOS already provide that?

Tom

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 21 Jul 2016 06:36:02 -0700

I haven;t talked much with mobile network operators. One data
point a US mobile operator gave me was about recognizing certain 
type p2p traffic that had real bad congestion control and was
monopolizing congested links. And then counter that. I am not sure
if this policing happened on some mobile link/path-segment or at
the edge to the non-mobile core.

Cheers
    Toerless

On Thu, Jul 21, 2016 at 02:40:12PM +0200, Frode Kileng wrote:
> [email-masked]

-- 
---
Toerless Eckert, [email-masked]

---

From: Frode Kileng <[email-masked]>
Date: Thu, 21 Jul 2016 15:36:42 +0200

> Doesn't DSCP/TOS already provide that?

Oh, I didn't intend to say this is a good idea, just one potential usage 
of PLUS as it has been identified. I do think there's need to do a lot 
of work to understand the pro/cons and how it should be implemented.

frodek

---

From: Frode Kileng <[email-masked]>
Date: Thu, 21 Jul 2016 15:54:46 +0200

> the edge to the non-mobile core.

Not sure about how relevant this example is for PLUS or for enabling 
mechanisms for helping traffic management in mobile networks. We could 
of course define a "Bad Congestion Implementation" path signal.... Or 
just ask such P2P apps to set the evil bit... :-)

IMHO we are at a state where we should demand facts and details to 
address features related to mobile network traffic management.

frodek

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 21 Jul 2016 16:47:37 +0200 (CEST)

> solving an existing problem related to mobile network management.

I know people that for instance have middle-boxes that drops unsolicited 
TCP SYN+ACK packets (no SYN was seen, now there is a SYN-ACK that the end 
system didn't seem to have requested).

This saves power for devices and it saves signaling resources in the 
ombile network. I've seen mobile networks melt down because of someone 
else being SYN-flooded with spoofed source addresses and the resulting 
"backscatter" was not doing the mobile network any good.

SPUD could be used to have similar benefits for non-TCP traffic, in that 
it might be easier to identify un-solicited traffic.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Frode Kileng <[email-masked]>
Date: Thu, 21 Jul 2016 17:03:56 +0200

On 21.07.2016 16:47, Mikael Abrahamsson wrote:
>
> SPUD could be used to have similar benefits for non-TCP traffic, in 
> that it might be easier to identify un-solicited traffic.

I'm not a native English speaker and I'm sorry if I was not clear enough 
in my initial e-mail. I was talking about existing operational practices 
hindered by end-to-end encryption and that PLUS can bring back (i.e. 
referring to a statement today that "mobile operators need PLUS").

Your example is covers new functionality to enable FWs/etc with 
"signaling and control impaired with respect to TCP" (As Joe Hildebrand 
stated on one of the slides on his presentation at the BoF). Except that 
a solution not requiring PLUS is preferable, there's nothing wrong with 
this IMHO.

frodek

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 21 Jul 2016 17:15:43 +0200 (CEST)

> referring to a statement today that "mobile operators need PLUS").

If all traffic is IPSEC encrypted and the SYN flag is no longer available 
to network operators, they can't do what I described. They can't do it 
either with various UDP protocols that people are now developing.

If SPUD comes with flags that say "this is a connection establishment 
packet" (SYN-like) and another flag that matches ACK, then middle boxes 
can track connection establishment for all traffic based on SPUD, without 
needing to know anything more about the traffic. This is the functionality 
I'm talking about.

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 21 Jul 2016 15:22:20 +0000

On 2016-07-21, at 17:15, Mikael Abrahamsson <[email-masked]> wrote:
> If SPUD comes with flags that say "this is a connection establishment packet" (SYN-like) and another flag that matches ACK, then middle boxes can track connection establishment for all traffic based on SPUD, without needing to know anything more about the traffic. This is the functionality I'm talking about.

I think Christian said much the same thing in an earlier email:

Why is the first packet arriving at a middlebox for which it has no binding not treated as such a "connection establishment packet"? Why does a bit need to be set for it to be treated as such?

Lars

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 21 Jul 2016 17:27:20 +0200 (CEST)

On Thu, 21 Jul 2016, Eggert, Lars wrote:

> Why is the first packet arriving at a middlebox for which it has no 
> binding not treated as such a "connection establishment packet"? Why 
> does a bit need to be set for it to be treated as such?

Because you still want to allow incoming connections to the customers from 
the Internet.

If there are no flags, I can't differentiate an incoming new connection 
Internet->UE (that I want to allow), from a backscatter packet (that I 
want to drop).

---

From: "Mishra, Sanjay" <[email-masked]>
Date: Thu, 21 Jul 2016 11:31:28 -0400

+1 Frode. Well said. 

-Sanjay

-----Original Message-----
From: Spud [mailto:[email-masked]] On Behalf Of Frode Kileng
Sent: Thursday, July 21, 2016 2:40 PM
To: [email-masked]
Subject: [E] [Spud] No. Operators don't need SPUD for mobile network management

Hi,

the claims that encryption has taken away something that was used for mobile network traffic management and that PLUS is needed to to save mobile network operations keeps surfacing, including at the BoF today. 
This view should not be interpreted as representing the view of all mobile operators

Best regards
Frode Kileng

---

From: Frode Kileng <[email-masked]>
Date: Thu, 21 Jul 2016 17:35:50 +0200

> does a bit need to be set for it to be treated as such?

Yes. And if needed, any return traffic can be used as an indicator that 
something is consenting to this traffic.

frodek

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 21 Jul 2016 17:38:53 +0200 (CEST)

> something is consenting to this traffic.

I don't understand this comment. You're getting SYN+ACK backscatter, if 
you forward them you'll melt the mobile network. The only way to discern 
if the user consents to the traffic, is to forward them.

How can this possibly work?

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 21 Jul 2016 15:33:07 +0000

On 2016-07-21, at 17:27, Mikael Abrahamsson <[email-masked]> wrote:
> If there are no flags, I can't differentiate an incoming new connection Internet->UE (that I want to allow), from a backscatter packet (that I want to drop).

We probably have different opinions on how important it is for a firewall to be able to drop backscatter vs. the ability for an app to benefit from 0-RTT. (Cue Lorenzo).

Lars

---

From: "Smith, Kevin, (R&D) Vodafone Group" <[email-masked]>
Date: Mon, 25 Jul 2016 10:49:28 +0000

Another operator here:  I like the notion of PLUS being used to hint to the TCP sender regarding network radio cell conditions, i.e. mobile throughput guidance[1].  So network information being sent out to help tune cwnd.

For sender to network: If there are ways to safely indicate open/close, 'drop me/queue me when I hit congestion', and 'I am a retransmitted packet' then that would be of interest too. But I fully respect the privacy concerns that were raised at the BoF, and would be happy to see a limited scope accordingly.

All best,
Kevin
Vodafone

[1] https://datatracker.ietf.org/doc/draft-flinck-mobile-throughput-guidance/ 

-----Original Message-----
From: Spud [mailto:[email-masked]] On Behalf Of Eggert, Lars
Sent: 21 July 2016 16:33
To: Mikael Abrahamsson
Cc: Frode Kileng; [email-masked]
Subject: Re: [Spud] No. Operators don't need SPUD for mobile network management

Lars

---

From: Christian Huitema <[email-masked]>
Date: Tue, 26 Jul 2016 17:46:17 +0000

On Monday, July 25, 2016 3:49 AM, Kevin Smith wrote:
> 
> Another operator here:  I like the notion of PLUS being used to hint to the TCP
> sender regarding network radio cell conditions, i.e. mobile throughput
> guidance[1].  So network information being sent out to help tune cwnd.

Isn't that already available from the modem?

> For sender to network: If there are ways to safely indicate open/close, 'drop
> me/queue me when I hit congestion', and 'I am a retransmitted packet' then
> that would be of interest too. But I fully respect the privacy concerns that were
> raised at the BoF, and would be happy to see a limited scope accordingly.

We are most likely to get consensus on simple issues like DDOS prevention and NAT traversal. The endpoints cannot really fight DDOS all by themselves, the damage is already done by the time the packets reach them, so this is certainly an area where there is a desire to collaborate. Currently the endpoints keep sending "keep alive" traffic every 15 to 30 seconds to maintain the state in the NAT and firewalls; finding something better would be nice.

-- Christian Huitema

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Tue, 26 Jul 2016 22:49:22 +0000

>Isn't that already available from the modem?

No, the UE only knows about its perceived radio quality.  The effective
amount of transport blocks (i.e., instantaneous throughput) assigned to a
given UE is decided by the base station, taking into account the state of
all the attached devices.

---

From: Tom Herbert <[email-masked]>
Date: Tue, 26 Jul 2016 20:05:00 -0700

> Another operator here:  I like the notion of PLUS being used to hint to the TCP sender regarding network radio cell conditions, i.e. mobile throughput guidance[1].  So network information being sen…
I am not a big fan of having middleboxes purposely parsing an
modifying TCP options, but I do like security considerations of mobile
guidance and hope that PLUS might adopt some of the same concepts.
Specifically:

"The protocol specified in this document assumes that a trustful
relationship between the Throughput Guidance Provider and the TCP
server has been formed"

and

"Throughput guidance is considered confidential information"

and

"The identity of the Mobile Throughput Guidance provider that injects
the throughput guidance header must be explicitly known to the
endpoint receiving the information."

Tom

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Wed, 27 Jul 2016 06:34:26 +0000

On 27/07/2016 04:05, "Spud on behalf of Tom Herbert"
<[email-masked] on behalf of [email-masked]> wrote:
>> Another operator here:  I like the notion of PLUS being used to hint to
>>the TCP sender regarding network radio cell conditions, i.e. mobile
>>throughput guidance[1].  So network information being sent out to help
>>tune cwnd.
>>

These security & privacy considerations are MTG-specific.  If (as I do
wish) MTG is ported to PLUS, MTG will have to define how security &
privacy of its own vocabulary is achieved.

Section 6.3 of draft-trammel-spud-reqs already has text that takes this
scenario into consideration:

   [...] SPUD should support different levels of
   trust than the default ("untrusted, but presumed honest due to
   limitations on the signaling vocabulary") and fully-authenticated;