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

[Dirk Kutscher <[e-mail]>]

Hi Sebastien,

Thanks a lot for the feedback -- we'll come back to that (hopefully soon).

Best regards,
Dirk

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of [e-mail]
> Sent: Samstag, 9. März 2013 01:03
> To: [e-mail]
> Subject: Re: [conex] I-D Action: draft-ietf-conex-mobile-01.txt
> 
> 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 À : i-d-
> [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.
> 
> _______________________________________________
> conex mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/conex