Subject: [conex] Review comments: draft-kutscher-conex-mobile-00

From: Bob Briscoe <[email-masked]>
Date: Wed, 06 Apr 2011 16:13:53 +0100

Dirk & co-authors,

General points:
---------------
* I liked the draft (perhaps because it was positive about ConEx ;) 
and found it well-written and very readable.
* It was often written the wrong way round, assessing whether mobile 
networks would be a good fit for ConEx, rather than assessing whether 
ConEx would be a good fit for mobile networks.
* It would be useful to describe the precise benefit that ConEx might 
add to mobile that would not be possible without it. Personally I 
think this has to do with providing a simple way to bring real-time 
cost information from throughout the network to the control point 
where customer policies are known and traffic control is applied (see later).
* The draft has a good structure and scope - whatever you change, 
please try to preseve these.

Technical points
----------------
1. Intro
"   where the UE (User Equipment,
    i.e. mobile end host), its access network and possibly an operator's
    core network can be CONEX-enabled.
"
Surely the servers or caches are the main nodes to ConEx enable?
It also needs to be made clear what it means to ConEx enable a 
network (ie place policy / audit functions at its edges).
3.1 ConEx as a basis for traffic management

I don't think we should be embarrassed to say that ConEx might be 
useful to DPI in the shorter term. Then, longer term, it provides an 
evolution path to achieve the main traffic management objectives of 
DPI, but in a neutral way.

This agnosticism is an incremental deployment strength of ConEx (when 
I first introduced re-ECN to the IETF, I described its benefits for 
network operators with either conservative or liberal policies - I 
was thinking of cellular walled gardens as the conservative case).

ConEx information can be used in two different ways, perhaps both at 
the same time on different traffic:
a) per flow policy-based traffic management (enhancing DPI)
b) bulk packet traffic management (replacing DPI)

Why ConEx helps DPI: DPI is effectively used for yield management, 
optimising revenue vs cost on a per-session basis. However, currently 
DPI only has cost information based on inference of likely future 
flow volume based on application type. ConEx would provide real-time 
cost information, so that this yield management could be based on 
actual network conditions, not guesses and inferences.

As you say, longer term ConEx allows the PCC architecture to be 
revisted. ConEx could be used to manage all traffic; except 'opt-in' 
traffic where the user equipment or server explicitly signals to the 
mobile network on a per-session basis.

I predict that the transition from a) to b) will occur as competition 
commoditises the session-based approach. Per-session yield management 
only makes sense while excess profits can be extracted from different 
sessions.

3.2.  CONEX to incentivize scavenger transports

"the mobile communication network will be used like any other access network, "
This is unclear to those who don't know how a mobile network 
currently tries to work: identifying all this traffic and trying to 
handle it all differently.

The second para is unclear and vague. Why will it eventually be 
difficult to distinguish the different apps? What exactly is 
reflected by current DPI activities?

3.3.  Accounting for Congestion Volume

This section is the first time received and sent are distinguished. 
This ought to have been already said earlier.

3.4 ConEx as a form of differential QoS

The point needs to be made here that ConEx info can be used in two 
different ways:
a) as additional info to help the network to impose different QoS for 
different sessions
b) so that the network can allow user equipment to take different 
amounts of bandwidth in response to congestion, but still enforce 
overall limits on the contribution to congestion.

This is a similar flow/bulk choice as discussed for DPI, which I 
think could be brought out more as a theme throughout the document.

3.5 Partial vs. Full Deployment

para1: conex-abstract-mech says the aim is for ConEx to be initially 
deployed solely on the sender. As well as the case of the 
ConEx-enabled UE (presumably as sender), this doc also needs to 
consider the much more prevalent case of a server or cache as sender, 
particularly a server/cache directly connected to the mobile network, 
which would be a very plausible deployment case.

para2: Roaming: It is relatively easy to shift the state associated 
with a policy device as a user roams. This is already done when the 
state associated with a user's account is shifted during a hand-over. 
You may want to refer to this paper on the design of a distributed policer:

Raghavan, B., Vishwanath, K., Ramabhadran, S., Yocum, K. & Snoeren, 
A.C., "Cloud control with distributed rate limiting," Proc. ACM 
SIGCOMM'07, Computer Communication Review 37(4):337--348 ACM (2007) 
DOI: http://doi.acm.org/10.1145/1282427.1282419

para3: It is right to mention that traffic offload may move the 
attachment point and therefore shift where policy has to be monitored 
and enforced. But it should also be pointed out that ConEx 
information would be likely to drive decisions to offload traffic in 
the first place, and lack of ConEx makes such decisions harder.

4.1 Possible Deployment Scenarios

I suggest an additional scenario 3) that is perhaps a more likely 
deployment. The sender supports ConEx and offers e2e ConEx info to 
nodes on the network path, but not all the networks on the path use 
the information or audit it.

Given we are likely to have a variant of ConEx that works with 
existing receivers, this will be an important partial deployment scenario.

"  the case when CONEX is only implemented in a few
    networks, or when operators decide to not expose and account for
    congestion for inter-domain traffic."

To be clear, operators cannot decide to not expose ConEx information 
if senders expose it. OK, the operator might bleach ConEx 
information, but this may break e2e authentication and consequently 
be considered somewhat equivalent to sending TCP resets to p2p 
applications >:-}

Perhaps you intended to talk about operators deciding not to expose 
ECN inter-domain?

4.2.  Implementing CONEX Functions in the EPS

ConEx function placement:
- First, you need to say which function you are talking about. I 
assume you mean the policy function.
- Second, ConEx information is unchanged along the whole path, so 
reading ConEx information should be placement-agnostic along the path.
- Third, placement is sensitive to ECN (or drop) information, which 
does change along the path. But, importantly, the operator can use 
tunnelling to preserve the ECN information as it was at a remote 
upstream point, which will be frozen in the inner header of the 
tunnel. Therefore, again, reading ECN info can be placement-agnostic 
along the path.
- Fourth, although monitoring information can be placement-agnostic, 
as you say, the action as a result will be placement-sensitive.
- Fifth, however, a case not considered is where a rudimentary 
policing function (e.g. bulk) is placed close to the edge, then a 
richer (e.g. per-flow) policing function is placed in a more 
centralised location. The outer policing function would protect 
sufficiently against unresponsive sources, while the inner policing 
function takes advantage of economies of scale for managing such 
complex policies.

Downlink policers at borders: Ought to mention the possibility of 
ConEx monitoring function at borders driving out-of-band mechanisms 
rather than direct policing intervention, eg. a border contract with 
penalties based on ConEx info.

5. Implications for ConEx
"     the mobile network may encounter
       longer delay and higher loss rate but most of the flows are short-
       lived.  "
I don't understand the connection between the two parts of this 
sentence. Why the word 'but'? In all networks, most flows are 
short-lived, and the Credit packets in ConEx are designed to provide 
the right incentives precisely for this case. What's different about 
mobile networks here?

Tunnelling: Could refer to draft-briscoe-tsvwg-ecn-encap-guidelines, 
although that only deals with tunnelling ECN, not ConEx.

Editorial
---------

1. Intro
s/CONEX, as described in [I-D.ietf-conex-concepts-uses] is a technology to/
  /CONEX, as described in [I-D.ietf-conex-concepts-uses], is a technology to/

2. Overview of 3GPPP...
Features described but not labelled in Fig 1:
EPC, eNB, P-GW,
s/GWs/gateways/

3. ConEx Use Cases
s/extend/extent/

3.1
s/create a certain dynamics/
  /create certain dynamics/

s/for bearers establishment/
  /for bearer establishment/

Expand 'PDN'.

s/Previously more static approach ... have been applied/
  /Previously more static approaches ... have been applied/

3.6
s/the 3GPP EPS in a system architecture that/
  /the 3GPP EPS is a system architecture that/

s/such as an LTE mobile communication networks/
  /such as an LTE mobile communication network/

4.1   Possible Deployment Scenarios
para2: would be useful to break down into enumerated bullets 
(especially if you add the 3rd scenario I suggest above)

4.2.  Implementing CONEX Functions in the EPS
s/re-act/react/

s/based on function related/
  /based on a function related/

"     implementations of CONEX may require the network to enforce proper
       congestion contribution declaration (i.e., as droppers in the Re-
       ECN proposal).
"
Ought to now reference the new terminology 'audit function' in 
conex-abstract-mech.

HTH

Thankyou again,

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Dirk Kutscher <[email-masked]>
Date: Wed, 6 Apr 2011 15:43:17 +0000

Bob,

excellent feedback -- thanks a lot!

One of the items on our todo list was exactly to elaborate on the real-time cost information benefit that ConEx can provide in this environment, so your input is really helpful.

We will consider this for the update.

Cheers,
Dirk

> -----Original Message-----
> From: Bob Briscoe [mailto:[email-masked]]
> Sent: Wednesday, April 06, 2011 5:14 PM
> To: Dirk Kutscher
> Cc: [email-masked]; ConEx IETF list
> Subject: Review comments: draft-kutscher-conex-mobile-00
> 
> Dirk & co-authors,
> 
> General points:
> ---------------