Re: [conex] I-D Action: draft-ietf-conex-mobile-01.txt

[<[e-mail]>]

Hi,

I reviewed this draft, which is of interest to me. Indeed, as said during the IETF83 in Paris, I believe that documenting how to use ConEx in the context of mobile networks would be beneficial to the industry, as it clearly corresponds to an interesting use case. I would be happy to help if useful.

Please see below some comments/questions for clarification, with the goal of improving this draft.


- Section 2: overview of 3GPP EPC

I am not convinced that this overview is really a must in this document, especially if the purpose is to publish it at the end. Referencing the relevant 3GPP documents might be appropriate instead. Also, I would suggest avoiding to make this draft specific to LTE; indeed ConEx is applicable to other mobile networks.

What could be of interest however in this section might be to describe in a generic way the aspects specific to the mobile networks relevant to ConEx, for instance:
	- the use very often of a tunnel "IP over IP" (GTP tunnel in general)
	- the fact that two very different segments are involved in those networks (wireless and backhaul/core)
	- the specificities of the wireless segment - e.g. the cost of transmitting a packet depends on the radio conditions
	- the mobility aspects, and their impact on the places where ConEx related information must be maintained
	- the potential presence of very different mobile technologies (e.g. 3GPP-based and Wifi) and offloading scenarios

The following draft that we briefly presented in Paris could give some inputs on the wireless segment: http://tools.ietf.org/pdf/draft-jobert-tsvwg-pre-congest-notif-mobile-00.pdf

In addition, I wonder if the scope of this document could also cover unlicensed wireless networks such as Wifi? Perhaps the architectures are a bit different, but maybe not too much. And I understood that Wifi is already part of the offloading scenarios described in this draft.


- Section 3: ConEx use cases

This draft mentions 4 different use case of ConEx in mobile networks:

	3.1- CONEX as a Basis for Traffic Management

The beginning of section 3.1 has again many references to 3GPP LTE mechanisms that are not really ConEx specific. It would be desirable to focus the discussion on ConEX: describe basically the features that ConEx would bring, and how to deploy the mechanism, without necessarily comparing with 3GPP LTE features.

DPI and admission control are mentioned. It is worth clarifying that DPI is clearly not used everywhere and has clear drawbacks (e.g. versatility of application signatures, trend to encryption). I would personally avoid presenting it as a de facto mechanism; there are other options to manage QoS in a dynamic way in mobile networks. It is worth also mentioning that the efficiency of admission control mechanisms for data services is quite limited in general in mobile networks, due to the high variability of the traffic and of the achievable throughput on the radio interface. My experience is that, most of the time, they are simply deactivated for data services.

When reading the text, I found the DPI discussion and comparison with ConEx quite unclear. These are 2 different mechanisms. As presented in the draft, DPI aims at identifying certain types of applications, to potentially apply a particular treatment to them in case of congestion. My understanding of ConEx is that it can tell you about how much congestion has been caused by a user or by a flow in the past. One might want to apply a particular treatment to the flows having causes the highest congestion in the past, but I believe that it is a different use case compared to the "service classification" mentioned with DPI - both could actually be complementary and combined. I don't fully agree that ConEx plays the same role as a mechanism which aims at identifying the type of application (DPI, or another mechanism). I don't believe either that it is "more accurate and dynamic fashion"; this is simply different paradigm.

The use case of data offload is also mentioned. While I understand the concept, I am not sure that I see how this is specific to ConEx. This is a bit similar to the previous discussion: one can apply various criteria to select the flows to be offloaded, ConEx providing information for a congestion-based selection. I'll tend to think that congestion will very likely not be the only criteria.

Again, I believe that the draft would benefit in simply describing how ConEx is expected to be used to address this kind of use cases, rather than comparing with other LTE mechanisms.


	3.2- CONEX to Incentivize Scavenger Transports

While I fully understand the objective of this (basically, incentivize the use of less-than-best-effort transport), I feel that this is more in the hands of the application than the network, and the application probably needs some trigger from the network to move to this kind of scavenger transport. Therefore, you might perhaps add that additional specific mechanisms could be implemented in the network, such as the one described in section 3.3 (Accounting for Congestion Volume), to really incentivize the applications to play the game.


	3.3- Accounting for Congestion Volume

IMHO, this is probably the most interesting use case for ConEx in mobile networks: providing a more accurate form of fair usage. How to use ConEx to address this use case should be better described in this document. The advantages of informing the application about the periods of congestion could be for instance highlighted. Also, the description could be combined with the previous use case described in section 3.2 (Scavenger Transports), since they are in a way complementary.


	3.4- CONEX as a Form of Differential QoS

I don't really see the main difference compared to section 3.1; could you clarify what is specific here? Perhaps both sections should be combined?


- Section 3.5: Partial vs. Full Deployment

This section is really important, as it is quite clear that ConEx will not be supported everywhere in potential early deployments. Especially, as mentioned in the draft, mobile terminals may not support the mechanisms at the beginning.

Some of the schemes suggested during partial deployments may however be difficult to be explained to the end user (e.g. "apply fixed volume caps for non-CONEX UEs and more flexible schemes for CONEX-enabled UEs"), and therefore difficult to consider in practice. This may moreover not always be a matter of mobile terminal, but also of the way the application running on the terminal is developed - hence the potential variability.

Migration paths and partial support for ConEx should be further detailed, in particular how to progressively introduce ConEx in mobile networks, e.g. in case the features are not supported everywhere. For instance, in case the terminals do not implement ConEx, could some ConEx functions be implemented in the base station instead? The draft is currently not so detailed on these aspects.

This section describes relevant areas where attention is required (roaming, mobility, ...). There is however some overlapping with previous section on ConEx-based data offload (it might be easily fixed).


- Section 4: ConEX in the EPS

The description of the 3 scenarios is currently very limited/weak (basically reduced to the figures...). Further details are clearly needed to understand them.

For instance, I don't understand how case 1 (figure 2) could work without the UE supporting ConEx. How can the server know about the amount of congestion in this case? My understanding of this scenario is that the UE does not even send back to the sender the congestion signal (e.g. ECN/loss) in the TCP layer.

It is not clear either how ConEx could operate over multiple administrative domains (e.g. multiple operators).

It should be discussed somewhere whether the purpose is to cover congestion only over the wireless segment, only over the backhaul segment, or both. A section discussing how to actually manage / differentiate congestion in the backhaul vs radio segment could be useful. Indeed, when ECN is used, this kind of consideration may be of importance. It was good point to reference RFC 6040 as propagation of the ECN marking across the (GTP) tunnel may be needed. Further details about the exact option(s) to be used could however be useful.

The draft should recommend more clearly where to position the different functions defined in ConEx, e.g.:
	- Policer in the core network (e.g. in the GGSN / PDN-GW)
	- Auditer in the base station
	- Support for ConEx in the mobile terminals (as senders or receivers)
	- Support for ConEx in the senders more in general (e.g. Web server)

While I understand the concept, I am not fully convinced about positioning the policer in the base station for the uplink direction; that seems really too much distributed for this kind of function. Probably it depends on the exact use case addressed, but if some form of user-specific accounting information is required to the policer, this position is clearly not a good option at all.


- Other comments

I have a general question to the group: which relationships do you see between ConEx and UPCON activities in 3GPP? They are touching the same aspects (namely congestions in wireless networks), but the mechanisms may at the end be quite different (although my understanding is that the mechanisms in UPCON are still to be defined).

For instance: 
	- Could ConEx be one possible solution to UPCON?
	- Will UPCON be an alternative to ConEx, where the congestion information will be carried back to the core network by another mean than TCP layer? (e.g. inside the GTP tunnel)
	- Can UPCON be considered as similar to a partial deployment of ConEx, and be completed later when the mobile terminals will be "ConEx aware"?

I'd be really interested to hear people's opinion on these items.

Thanks.

Cheers,

Sébastien

-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] De la part de [e-mail]
Envoyé : jeudi 10 janvier 2013 09:19
À : [e-mail]
Cc : [e-mail]
Objet : [conex] I-D Action: draft-ietf-conex-mobile-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Congestion Exposure Working Group of the IETF.

	Title           : Mobile Communication Congestion Exposure Scenario
	Author(s)       : Dirk Kutscher
                          Faisal Ghias Mir
                          Rolf Winter
                          Suresh Krishnan
                          Ying Zhang
                          Carlos J. Bernardos
	Filename        : draft-ietf-conex-mobile-01.txt
	Pages           : 22
	Date            : 2013-01-10

Abstract:
   This memo describes a mobile communications use case for congestion
   exposure (CONEX) with a particular focus on mobile communication
   networks such as 3GPP Evoled Packet System (EPS).  The draft provides
   a brief overview of the architecture of these networks (both access
   and core networks), current QoS mechanisms and then discusses how
   congestion exposure concepts could be applied.  Based on this, this
   memo suggests a set of requirements for CONEX mechanisms that
   particularly apply to mobile networks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-conex-mobile

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-conex-mobile-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-conex-mobile-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
conex mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/conex

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.