Re: [conex] Draft "Pre-congestion notification in mobile networks"

<sebastien.jobert@orange.com> Mon, 12 March 2012 23:16 UTC

Return-Path: <sebastien.jobert@orange.com>
X-Original-To: conex@ietfa.amsl.com
Delivered-To: conex@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5066221E8133 for <conex@ietfa.amsl.com>; Mon, 12 Mar 2012 16:16:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.026
X-Spam-Level:
X-Spam-Status: No, score=-6.026 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzdbN3aetpcp for <conex@ietfa.amsl.com>; Mon, 12 Mar 2012 16:16:20 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4098921E812C for <conex@ietf.org>; Mon, 12 Mar 2012 16:16:20 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 723F7DE4003; Tue, 13 Mar 2012 00:17:49 +0100 (CET)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 5ECA9DE4002; Tue, 13 Mar 2012 00:17:49 +0100 (CET)
Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Mar 2012 00:16:18 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD00A6.211224D7"
Date: Tue, 13 Mar 2012 00:16:16 +0100
Message-ID: <AFC377AFCC0FBD4DABE49F4B81EC4F1A03554BDC@ftrdmel1>
In-Reply-To: <1220E2C537595D439C5D026E83751866220398FC@ex-mb1.corp.adtran.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Draft "Pre-congestion notification in mobile networks"
Thread-Index: Acz9jrbRNPBod6S3QWSO/G4dZZpM1QC2Qa8QAA6dXvA=
References: <AFC377AFCC0FBD4DABE49F4B81EC4F1A03520051@ftrdmel1> <1220E2C537595D439C5D026E83751866220398FC@ex-mb1.corp.adtran.com>
From: sebastien.jobert@orange.com
To: stuart.venters@adtran.com
X-OriginalArrivalTime: 12 Mar 2012 23:16:18.0762 (UTC) FILETIME=[215852A0:01CD00A6]
Cc: conex@ietf.org
Subject: Re: [conex] Draft "Pre-congestion notification in mobile networks"
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Congestion Exposure working group discussion list <conex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/conex>, <mailto:conex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/conex>
List-Post: <mailto:conex@ietf.org>
List-Help: <mailto:conex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/conex>, <mailto:conex-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 23:16:23 -0000

Hi Stuart,

 

The definition of fairness in wireless networks is indeed not so simple...

In general, the trade-off between capacity and fairness is handled by the algorithms developed in the radio schedulers.

 

>From the ConEx perspective, the key point that we wanted to highlight was that it might be useful to blame more the users in bad radio conditions in terms of congestion-volume counting when the network is overloaded, since they use more radio resources for the same amount of traffic to be carried. It would provide incentives to delay some non-urgent data consumptions to periods when the radio conditions will be better, or when the network will be less loaded.

 

And because the congestion-volume may be related to the ECN marking algorithms, it seems also useful to further investigate how the ECN marking is currently supported over the wireless segment.

 

Thanks.

 

Cheers,

 

Sébastien

 

De : STUART VENTERS [mailto:stuart.venters@adtran.com] 
Envoyé : lundi 12 mars 2012 17:00
À : JOBERT Sebastien RD-CORE-LAN
Cc : conex@ietf.org
Objet : RE: Draft "Pre-congestion notification in mobile networks"

 

Sebastien,

 

You bring up an interesting point about fairness in a wireless network.

 

Since the radio path quality may be different from handset to handset,

    the amount of radio resources required to transport a given number of bits may also be different.

 

To be fair, should each handset get the same number of bits or the same number of radio resources?

  (Or, more likely,  as you suggest in section 6, a combination of the two.)

 

This seems as much a marketing issue as a technical one, so I would expect each carrier to want to be able to choose the cost function combining these two factors.  I agree with you that just counting the bytes is not enough.

 

 

Cheers,

 

Stuart

 

 

 

 

 

 

 

________________________________

From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of sebastien.jobert@orange.com
Sent: Thursday, March 08, 2012 6:51 PM
To: conex@ietf.org
Cc: isabelle.hamchaoui@orange.com
Subject: [conex] Draft "Pre-congestion notification in mobile networks"

Hi all,

 

We have uploaded an Internet-Draft called "Pre-congestion notification in mobile networks" - http://www.ietf.org/id/draft-jobert-tsvwg-pre-congest-notif-mobile-00.pdf

 

Abstract

 

   Mobile networks may be divided into two main segments: the radio

   segment, and the wireline segment. This document highlights that the

   algorithms leading to pre-congestion notification (e.g. ECN marking)

   are usually significantly different for these two segments, and not

   defined or documented in general over the radio segment. It also

   explains that using ECN bits leads to having a unique signal for

   notifying a pre-congestion related to two separate segments with

   very different notification algorithms. Some consequences are

   questioned, as well as the potential benefits of being able to

   identify where the congestion comes from. This document finally

   discusses the possibility to take into account the radio conditions

   of the terminals when counting the volume of congestion over the

   radio segment.

 

It has been posted in TSVWG, but some aspects discussed in this draft are related to discussions in CONEX, and might be of interest to the WG.

We are interested by review and comments.

 

Thanks.

 

Best Regards,

 

Sébastien JOBERT
Orange Expert, network synchronization and QoS in mobile networks
Orange Labs, Networks & Carriers - France Telecom Orange
sebastien.jobert@orange.com <mailto:sebastien.jobert@orange-ftgroup.com>