From sebastien.jobert@orange.com Wed May 9 13:48:40 2012 Return-Path: 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 3A8D811E80CA for ; Wed, 9 May 2012 13:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.248 X-Spam-Level: X-Spam-Status: No, score=-1.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, 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 UgedQT+Lm-CS for ; Wed, 9 May 2012 13:48:34 -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 5AAB911E8079 for ; Wed, 9 May 2012 13:48:33 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1099FA44261; Wed, 9 May 2012 22:50:05 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id EFC58A44260; Wed, 9 May 2012 22:50:04 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 May 2012 22:48:31 +0200 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_01CD2E25.17C1580A" Date: Wed, 9 May 2012 22:48:30 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECN marking over wireless networks Thread-Index: Ac0uJRcyf5ZzZzDRRHmZRK2XKz/+HA== From: To: , X-OriginalArrivalTime: 09 May 2012 20:48:31.0912 (UTC) FILETIME=[183FE280:01CD2E25] Subject: [conex] ECN marking over wireless networks X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 20:48:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD2E25.17C1580A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 There has been some discussion during the IETF 83 in Paris in ICCRG and = CONEX WG about relevant ECN marking algorithms over wireless networks. Some aspects related to this topic are discussed in this draft: = http://www.ietf.org/id/draft-jobert-tsvwg-pre-congest-notif-mobile-00.pdf= , briefly introduced during ICCRG meeting. This email aims at starting some discussion on the mailing lists of = ICCRG and CONEX, as requested by the chairs after the discussions during = IETF 83. =20 Essentially, the main aspect pointed out during the discussions was that = there might benefits in taking into account the radio conditions of the = mobile terminal for ECN marking over the radio segment and for = congestion-volume counting. The reason for this is that it requires more = radio resources to transmit the same amount of data to a terminal in bad = radio conditions compared to a terminal in good radio conditions. =20 As an introduction to the discussion, it might be useful to mention that = different potential use cases for ECN marking involving the mobile = terminal could be envisaged: 1. interaction with TCP 2. adapt the coding rate of adaptive application (e.g. adaptive = streaming, etc.), as suggested in 3GPP TS 36.300 document 3. stop/delay the non-urgent applications (background tasks in the = terminal, etc.) 4. congestion-volume counting (as for Conex related use cases) =20 This list is obviously non-exhaustive, and shows that depending on the = final utilization of the congestion notification, different algorithms = for ECN marking over the radio segment might be imagined. The most = optimal algorithm certainly depends on the final objective. =20 >From the comments received during the discussion, it seems that the = first ECN marking algorithm over the radio segment that comes to most = people's mind is to consider an average queue length exceeding a given = threshold, as for RED. It should be noted that because the radio segment = shares the radio resource among several terminals, one dedicated queue = per terminal is in general considered. =20 Therefore, if one would like to apply RED over a wireless segment, it = should be clarified whether it would be applied independently on each = dedicated queue per terminal (n instances of RED considered for the = radio segment), or on the sum of all the dedicated queues (1 single = instance of RED considered for the radio segment). This would lead to = two different ECN marking criteria: 1. RED based on the individual queue of each terminal 2. RED based on a single shared queue between all the terminals =20 Several remarks were raised during the presentation of the draft in = ICCRG and the discussion in CONEX: =20 - On the interactions with TCP (use case #1 listed above), it = was mentioned that TCP works on a longer timescale relative to the = wireless channel. In other words: the radio conditions may vary more = quickly than TCP reactions. This is correct, however, it should be = mentioned that the objective of ECN marking over the radio segment is = not to replace the existing radio schedulers, which already provide a = suitable control loop over these shorter time scales. As an example, the = very common Proportional Fair (PF) algorithm aims at addressing exactly = this point, by trying to optimize the allocation of radio resources (the = terminals in good instantaneous radio conditions are favored compared to = the others, as to optimize the cell capacity, while certain fairness is = ensured in the longer term by taking into account also the averaged = throughputs delivered to the terminals). =20 - Still regarding the interactions with TCP (use case #1 listed = above), assume now that a PF algorithm is used to control the allocation = of radio resources. It was mentioned also that if it is assumed that ECN = marking is done according to the individual queue of each terminal = (criteria #1 listed above), then a terminal in bad radio conditions will = already experience ECN marking more often without the need to weight the = probability of the ECN marking with the radio conditions of the = terminal. This is due to the fact that PF provides higher throughput to = terminals in good averaged radio conditions than in bad averaged radio = conditions. Actually, the amount of ECN marking will depend in this case = whether the throughput required to transmit the data to a particular = terminal is lower than the throughput provided to this terminal by PF; = if not, then no ECN marking should happen for this terminal in these = conditions (even during congested periods actually).=20 =20 - Based on this discussion, it seems to me that the interaction = of ECN marking with TCP should not be analyzed in terms of benefits it = brings to control the allocation of resources over the radio segment, = which is already under the control of the radio scheduler. It seems that = this second control loop provided by ECN marking interacting with TCP = would rather aim at indicating when the traffic rate of a terminal = exceeds the throughput provided by PF to this terminal, which could be = useful for use case #2 (coding rate adaptation). Basically, it is = expected that this second control loop would try to "align" with the = throughput provided by the first one (keeping in mind that PF provides = throughputs varying with time). =20 - The same example but now with the ECN marking criteria #2 = instead of #1 raises however issues. Indeed, in case the throughput = required to transmit the data to one particular terminal is lower than = the throughput provided to this terminal, this will lead to ECN marking = for all the terminals, even the ones below the PF throughput, which is a = situation that should be avoided when interaction with TCP is desirable. = Excessive traffic consumption on one terminal should not impact the = others (i.e. should not lead to the generation of ECN marking for the = others). Definitely, the criteria #1 does not seem a good idea when = interaction with TCP is desired. =20 - Considering the use case #3 depicted earlier now, it should = be noted however that the previous situation with PF + ECN marking based = on individual queues (criteria #1) has some limitation. Indeed, in case = of radio congestion (assume here that radio congestion means that all = the radio resources are used and are not enough to transmit all the data = to be transmitted to all the terminals - a more accurate definition = might be found), some of the terminals may not received ECN marking, as = indicated before (in case they require less than what PF can provide to = them). Perhaps some of the data transmitted to these non-notified = terminals are not so critical and might be delayed, as to free resources = to the other users with more important traffic to be exchanged. The = depicted situation does not provide incentives to do this, because ECN = marking only applies to some users. It is the reason why it might be = interesting to consider other ECN marking algorithms (which might not = aim at interacting necessarily with TCP; BTW not all the applications = are running over TCP), as to inform about the congestion situation. The = idea is to say to the end user: "Hey! The system starts being full, the = PF algorithm will still provide you with some network resources, but if = some of your data can be delayed, please do so!" Of course, this kind of = approach might be coupled with congestion-volume counting / CONEX use = cases, to provide incentives. =20 - Let's take a practical example to illustrate (note sure it is = the best one, but it is the one that comes to my mind...): you need to = go to some administration to collect some administrative document - say, = a voting card to elect your new president. There is already a long = queue, but you could pass with a "certain priority" because what you = need to do is faster than what other people have to do. However, if you = collect your document, you consume resources of the system that will not = be available to the others during this time - the person in front of you = will be busy giving you your document. And what you need to do is not = urgent - the election is not tomorrow, you will have time to come back = later. Perhaps you would like to be fair with the other people having = more urgent things to do and waiting in the queue, and you will not wait = and instead come back later? And perhaps a signal indicating the = congestion might be useful (it is probably good to know if the queue is = long or not, rather than waiting without information). =20 - Considering the use case #4 depicted earlier now on = congestion-volume counting: it seems logical to me that the count would = take into account the real network resource usage rather than simply the = number of bits transmitted. This would provide again incentives to users = in bad radio conditions to delay non-urgent network usage. Moreover, an = interesting question which should be raised would be to define what = corresponds to a "congested period" for the radio segment: is it only = when the terminal exceeds its PF rate, or should a congestion period be = considered when the system starts being full/is full? This might trigger = different ECN marking algorithms on the wireless segment.=20 =20 I had noted two other comments from the discussions in IETF 83: - TCP middlebox accelerating TCP window growth: some comment = was made on the mic, however I am not sure that I understood what this = device is supposed to do; would anyone of you have some reference on = this? - Retransmission over the radio segment: should it be taken = into account as well for congestion-volume counting? It would mean that = a lost packet that is retransmitted by the low layers should be counted = twice? (after all, if it was retransmitted by TCP, it would have been = counted twice as well, right?) =20 Feedback on this discussion is welcomed. Thanks in advance. =20 Cheers, =20 S=E9bastien JOBERT Orange Expert "Future Networks", network synchronization and QoS in = mobile networks Orange Labs, Networks & Carriers - France Telecom R&D sebastien.jobert@orange.com = =20 =20 =20 ------_=_NextPart_001_01CD2E25.17C1580A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

There has been some discussion during the IETF 83 in Paris = in ICCRG and CONEX WG about relevant ECN marking algorithms over = wireless networks.

Some aspects related to this topic are discussed in this = draft: http://www.ietf.org/id/draft-jobert-tsvwg-pre-congest-notif-mob= ile-00.pdf, briefly introduced during ICCRG = meeting.

This email aims at starting some discussion on the mailing = lists of ICCRG and CONEX, as requested by the chairs after the = discussions during IETF 83.

 

Essentially, the main aspect = pointed out during the discussions was that there might benefits in = taking into account the radio conditions of the mobile terminal for ECN = marking over the radio segment and for congestion-volume counting. The = reason for this is that it requires more radio resources to transmit the = same amount of data to a terminal in bad radio conditions compared to a = terminal in good radio conditions.

 

As an introduction to the = discussion, it might be useful to mention that different potential = use cases for ECN marking involving the mobile terminal could be = envisaged:

1.       = interaction with TCP

2.       = adapt the coding rate of adaptive application (e.g. = adaptive streaming, etc.), as suggested in 3GPP TS 36.300 = document

3.       = stop/delay the non-urgent applications (background tasks in = the terminal, etc.)

4.       = congestion-volume counting (as for Conex related use = cases)

 

This list is obviously non-exhaustive, and shows that = depending on the final utilization of the congestion notification, = different algorithms for ECN marking over the radio segment might be = imagined. The most optimal algorithm certainly depends on the final = objective.

 

From the comments received during the discussion, it seems that = the first ECN marking algorithm over the radio segment that comes to = most people’s mind is to consider an average queue length = exceeding a given threshold, as for RED. It should be noted that because = the radio segment shares the radio resource among several terminals, one = dedicated queue per terminal is in general = considered.

 

Therefore, if one would like to apply RED over a wireless segment, = it should be clarified whether it would be applied independently on each = dedicated queue per terminal (n instances of RED considered for the = radio segment), or on the sum of all the dedicated queues (1 single = instance of RED considered for the radio segment). This would lead to = two different ECN marking criteria:

1.       = RED based on the individual queue of each = terminal

2.       = RED based on a single shared queue between all the = terminals

 

Several remarks were raised during the presentation of the = draft in ICCRG and the discussion in CONEX:

 

-          = On the interactions with TCP (use case #1 listed above), it = was mentioned that TCP works on a longer timescale relative to the = wireless channel. In other words: the radio conditions may vary more = quickly than TCP reactions. This is correct, however, it should be = mentioned that the objective of ECN marking over the radio segment is = not to replace the existing radio schedulers, which already provide a = suitable control loop over these shorter time scales. As an example, the = very common Proportional Fair (PF) algorithm aims at addressing exactly = this point, by trying to optimize the allocation of radio resources (the = terminals in good instantaneous radio conditions are favored compared to = the others, as to optimize the cell capacity, while certain fairness is = ensured in the longer term by taking into account also the averaged = throughputs delivered to the terminals).

 

-          = Still regarding the interactions with TCP (use case #1 = listed above), assume now that a PF algorithm is used to control the = allocation of radio resources. It was mentioned also that if it is = assumed that ECN marking is done according to the individual queue of = each terminal (criteria #1 listed above), then a terminal in bad radio = conditions will already experience ECN marking more often without the = need to weight the probability of the ECN marking with the radio = conditions of the terminal. This is due to the fact that PF provides = higher throughput to terminals in good averaged radio conditions than in = bad averaged radio conditions. Actually, the amount of ECN marking will = depend in this case whether the throughput required to transmit the data = to a particular terminal is lower than the throughput provided to this = terminal by PF; if not, then no ECN marking should happen for this = terminal in these conditions (even during congested periods actually). =

 

-          = Based on this discussion, it seems to me that the = interaction of ECN marking with TCP should not be analyzed in terms of = benefits it brings to control the allocation of resources over the radio = segment, which is already under the control of the radio scheduler. It = seems that this second control loop provided by ECN marking interacting = with TCP would rather aim at indicating when the traffic rate of a = terminal exceeds the throughput provided by PF to this terminal, which = could be useful for use case #2 (coding rate adaptation). Basically, it = is expected that this second control loop would try to = “align” with the throughput provided by the first one = (keeping in mind that PF provides throughputs varying with = time).

 

-          = The same example but now with the ECN marking criteria #2 = instead of #1 raises however issues. Indeed, in case the throughput = required to transmit the data to one particular terminal is lower than = the throughput provided to this terminal, this will lead to ECN marking = for all the terminals, even the ones below the PF throughput, which is a = situation that should be avoided when interaction with TCP is desirable. = Excessive traffic consumption on one terminal should not impact the = others (i.e. should not lead to the generation of ECN marking for the = others). Definitely, the criteria #1 does not seem a good idea when = interaction with TCP is desired.

 

-          = Considering the use case #3 depicted earlier now, it should = be noted however that the previous situation with PF + ECN marking based = on individual queues (criteria #1) has some limitation. Indeed, in case = of radio congestion (assume here that radio congestion means that all = the radio resources are used and are not enough to transmit all the data = to be transmitted to all the terminals – a more accurate = definition might be found), some of the terminals may not received ECN = marking, as indicated before (in case they require less than what PF can = provide to them). Perhaps some of the data transmitted to these = non-notified terminals are not so critical and might be delayed, as to = free resources to the other users with more important traffic to be = exchanged. The depicted situation does not provide incentives to do = this, because ECN marking only applies to some users. It is the reason = why it might be interesting to consider other ECN marking algorithms = (which might not aim at interacting necessarily with TCP; BTW not all = the applications are running over TCP), as to inform about the = congestion situation. The idea is to say to the end user: “Hey! = The system starts being full, the PF algorithm will still provide you = with some network resources, but if some of your data can be delayed, = please do so!” Of course, this kind of approach might be coupled = with congestion-volume counting / CONEX use cases, to provide = incentives.

 

-          = Let’s take a practical example to illustrate (note = sure it is the best one, but it is the one that comes to my = mind…): you need to go to some administration to collect some = administrative document – say, a voting card to elect your new = president. There is already a long queue, but you could pass with a = “certain priority” because what you need to do is faster = than what other people have to do. However, if you collect your = document, you consume resources of the system that will not be available = to the others during this time – the person in front of you will = be busy giving you your document. And what you need to do is not urgent = – the election is not tomorrow, you will have time to come back = later. Perhaps you would like to be fair with the other people having = more urgent things to do and waiting in the queue, and you will not wait = and instead come back later? And perhaps a signal indicating the = congestion might be useful (it is probably good to know if the queue is = long or not, rather than waiting without = information).

 =

-          = Considering the use case #4 depicted earlier now on = congestion-volume counting: it seems logical to me that the count would = take into account the real network resource usage rather than simply the = number of bits transmitted. This would provide again incentives to users = in bad radio conditions to delay non-urgent network usage. Moreover, an = interesting question which should be raised would be to define what = corresponds to a “congested period” for the radio segment: = is it only when the terminal exceeds its PF rate, or should a congestion = period be considered when the system starts being full/is full? This = might trigger different ECN marking algorithms on the wireless segment. =

 

I had noted two other comments from the discussions in IETF = 83:

-          = TCP middlebox accelerating TCP window growth: some comment = was made on the mic, however I am not sure that I understood what this = device is supposed to do; would anyone of you have some reference on = this?

-          = Retransmission over the radio segment: should it be taken = into account as well for congestion-volume counting? It would mean that = a lost packet that is retransmitted by the low layers should be counted = twice? (after all, if it was retransmitted by TCP, it would have been = counted twice as well, right?)

 

Feedback on this discussion is = welcomed. Thanks in advance.

 

Cheers,

 

S=E9bastien = JOBERT
Orange = Expert "Future Networks", network synchronization and QoS in = mobile networks
Orange Labs, Networks & Carriers - France Telecom = R&D
sebastien.jobert@orange.com

 

 

------_=_NextPart_001_01CD2E25.17C1580A-- From internet-drafts@ietf.org Thu May 10 10:26:09 2012 Return-Path: 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 02AB921F8731; Thu, 10 May 2012 10:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 SAyLddTiSk7D; Thu, 10 May 2012 10:26:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5380D21F8722; Thu, 10 May 2012 10:26:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120510172608.15327.97961.idtracker@ietfa.amsl.com> Date: Thu, 10 May 2012 10:26:08 -0700 Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-tcp-modifications-02.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 17:26:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion Exposure Working Group of = the IETF. Title : TCP modifications for Congestion Exposure Author(s) : Mirja Kuehlewind Richard Scheffenegger Filename : draft-ietf-conex-tcp-modifications-02.txt Pages : 14 Date : 2012-05-10 Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by previous packets on the same flow. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-conex-tcp-modifications-02.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-conex-tcp-modifications-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-tcp-modifications/ From mirja.kuehlewind@ikr.uni-stuttgart.de Thu May 10 10:31:34 2012 Return-Path: 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 302D711E808F for ; Thu, 10 May 2012 10:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 QqXbqm02kqXb for ; Thu, 10 May 2012 10:31:33 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDB111E809B for ; Thu, 10 May 2012 10:31:33 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 4402E633B1; Thu, 10 May 2012 19:31:31 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 32FB059A8A; Thu, 10 May 2012 19:31:31 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: Matt Mathis , Janardhan Iyengar Date: Thu, 10 May 2012 19:31:30 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201205101931.30539.mkuehle@ikr.uni-stuttgart.de> Cc: conex@ietf.org Subject: [conex] Fwd: New Version Notification for draft-ietf-conex-tcp-modifications-02.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 17:31:34 -0000 Hi Matt, hi Jana, I submitted a new version of the ConEx TCP Mod Draft. I believe you volunteered to review the document. There are currently two ToDos left. One is about a more generic description how set the right number of credits regarding the congestion control that is used. I think, Matt, you had some idea here already. Maybe you can provide some feedback here as well. The other one is the question if further action needs to be take if ConEx markings got lost. I guess I will post this question separately on the mailing list. Thanks in advance, Mirja ---------- Forwarded Message ---------- Subject: New Version Notification for draft-ietf-conex-tcp-modifications-02.txt Date: Thursday 10 May 2012, 19:26:08 From: internet-drafts@ietf.org To: mirja.kuehlewind@ikr.uni-stuttgart.de CC: rs@netapp.com A new version of I-D, draft-ietf-conex-tcp-modifications-02.txt has been successfully submitted by Mirja Kuehlewind and posted to the IETF repository. Filename: draft-ietf-conex-tcp-modifications Revision: 02 Title: TCP modifications for Congestion Exposure Creation date: 2012-05-10 WG ID: conex Number of pages: 14 Abstract: Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by previous packets on the same flow. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP). The IETF Secretariat ------------------------------------------------------- From ingemar.s.johansson@ericsson.com Fri May 18 06:10:35 2012 Return-Path: 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 E3EF821F8657 for ; Fri, 18 May 2012 06:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 yVj6-I7MIk5c for ; Fri, 18 May 2012 06:10:34 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D20C021F864B for ; Fri, 18 May 2012 06:10:32 -0700 (PDT) X-AuditID: c1b4fb30-b7be1ae0000059fc-c3-4fb64a4742e5 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 55.6D.23036.74A46BF4; Fri, 18 May 2012 15:10:31 +0200 (CEST) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.163]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 18 May 2012 15:10:30 +0200 From: Ingemar Johansson S To: =?iso-8859-1?Q?Mirja_K=FChlewind?= , Matt Mathis , Janardhan Iyengar Date: Fri, 18 May 2012 15:10:26 +0200 Thread-Topic: [conex] Fwd: New Version Notification for draft-ietf-conex-tcp-modifications-02.txt Thread-Index: Ac0u31GApn+CXGdLQISK+PqggyceFgGEx2Cg Message-ID: References: <201205101931.30539.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: <201205101931.30539.mkuehle@ikr.uni-stuttgart.de> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "conex@ietf.org" Subject: Re: [conex] Fwd: New Version Notification for draft-ietf-conex-tcp-modifications-02.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 13:10:35 -0000 Hi Thanks for a great effort to get this in order. Some comments, even though I haven't had the time to follow all the details= in ConEx I still hope they can be of some value.=20 I have not scrutinized the computation of CEG and LEG in detail but I foll= ow the discussion and it makes sense. Question, has anybody done any simula= tion experiments on this ? Comments/questions: Section 4.1, last sentence: First I did not understand it at all but I beli= eve that I get it now.. Maybe not important but perhaps one can rewrite it = like The CEG and LEG counters SHOULD be reset if any of these conditions occur: 1) One RTT since they was last decreased 2) One RTT after (loss?) recovery if no further congestion Not sure if this makes things more simple...=20 Section 4.2: This is IMHO the most complicated part. I fail to understand why it is suff= icient with a number of credits which is half the number of packet in fligh= t. Is this some kind of educated estimate ?. Probably I need to get this ex= plained better but there is a chance that other need it too. As regards to the statement that credit marks are only needed in slow start= . Cubic's cubic function may make it necessary to add extra credit marks to= avoid the flows being penalized in the audit functions or? Section 4.3: One complicating matter in e.g LTE is that the audit function needs to be i= n the eNodeB, at handover the audit state will be lost unless it is communi= cated to the other eNodeB via the X2 interface. Nothing that needs mention = in this document but it is worth mention anyway. Section 5: "The sender MUST NOT delay the ConEx signal more than one RTT" : This has i= mplications for instance for WebRTC as it puts a strict requirement to feed= back the actual congestion information in a timely manner. As of today the = discussion in WebRTC is around feedback of rate request information rather = than congetsion information. Again, nothing that needs to be mentioned in t= his doc but should probably be considered if the congetsion control WG for = WebRTC is formed. /Ingemar Nits: Page 8: "No congestion feedback information are available" --> "No congesti= on feedback information is available" Page 9: " Thus these packet.." --> " Thus these packets.." "These packet" --> "These packets" "unset" --> "reset" ? Page 11: "contributed with this.." --> "contributed with his" ?=20 =20 > -----Original Message----- > From: Mirja K=FChlewind [mailto:mirja.kuehlewind@ikr.uni-stuttgart.de]=20 > Sent: den 10 maj 2012 19:32 > To: Matt Mathis; Janardhan Iyengar > Cc: conex@ietf.org > Subject: [conex] Fwd: New Version Notification for=20 > draft-ietf-conex-tcp-modifications-02.txt >=20 > Hi Matt, hi Jana, >=20 > I submitted a new version of the ConEx TCP Mod Draft. I=20 > believe you volunteered to review the document. >=20 > There are currently two ToDos left. One is about a more=20 > generic description how set the right number of credits=20 > regarding the congestion control that is used. I think, Matt,=20 > you had some idea here already. Maybe you can provide some=20 > feedback here as well. > The other one is the question if further action needs to be=20 > take if ConEx markings got lost. I guess I will post this=20 > question separately on the mailing list. >=20 > Thanks in advance, > Mirja >=20 >=20 > ---------- Forwarded Message ---------- >=20 > Subject: New Version Notification for > draft-ietf-conex-tcp-modifications-02.txt > Date: Thursday 10 May 2012, 19:26:08 > From: internet-drafts@ietf.org > To: mirja.kuehlewind@ikr.uni-stuttgart.de > CC: rs@netapp.com >=20 > A new version of I-D,=20 > draft-ietf-conex-tcp-modifications-02.txt has been=20 > successfully submitted by Mirja Kuehlewind and posted to the=20 > IETF repository. >=20 > Filename: draft-ietf-conex-tcp-modifications > Revision: 02 > Title: TCP modifications for Congestion Exposure > Creation date: 2012-05-10 > WG ID: conex > Number of pages: 14 >=20 > Abstract: > Congestion Exposure (ConEx) is a mechanism by which senders inform > the network about the congestion encountered by previous packets on > the same flow. This document describes the necessary modifications > to use ConEx with the Transmission Control Protocol (TCP). >=20 > =20 > =20 >=20 >=20 > The IETF Secretariat >=20 > ------------------------------------------------------- >=20 > = From mirja.kuehlewind@ikr.uni-stuttgart.de Thu May 24 02:42:04 2012 Return-Path: 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 56E2721F85E7 for ; Thu, 24 May 2012 02:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 yZ4F0jQ7AfgC for ; Thu, 24 May 2012 02:42:03 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9A65F21F85E5 for ; Thu, 24 May 2012 02:42:02 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 43A32633B1; Thu, 24 May 2012 11:42:01 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 3020059A8A; Thu, 24 May 2012 11:42:01 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: Ingemar Johansson S Date: Thu, 24 May 2012 11:42:00 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201205101931.30539.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201205241142.00428.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: "conex@ietf.org" Subject: Re: [conex] Fwd: New Version Notification for draft-ietf-conex-tcp-modifications-02.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 09:42:04 -0000 Hi Ingemar, thanks a lot for your feedback! See some comments inline... Mirja On Friday 18 May 2012 15:10:26 Ingemar Johansson S wrote: > Hi > > Thanks for a great effort to get this in order. > > Some comments, even though I haven't had the time to follow all the detai= ls > in ConEx I still hope they can be of some value. > > I have not scrutinized the computation of CEG and LEG in detail but I > follow the discussion and it makes sense. Question, has anybody done any > simulation experiments on this ? Not yet, but it's on my todo list. > > Comments/questions: > Section 4.1, last sentence: First I did not understand it at all but I > believe that I get it now.. Maybe not important but perhaps one can rewri= te > it like The CEG and LEG counters SHOULD be reset if any of these conditio= ns > occur: 1) One RTT since they was last decreased > 2) One RTT after (loss?) recovery if no further congestion > Not sure if this makes things more simple... Yes, makes sense. I'll rewrite. > > Section 4.2: > This is IMHO the most complicated part. I fail to understand why it is > sufficient with a number of credits which is half the number of packet in > flight. Is this some kind of educated estimate ?. Probably I need to get > this explained better but there is a chance that other need it too. As > regards to the statement that credit marks are only needed in slow start. > Cubic's cubic function may make it necessary to add extra credit marks to > avoid the flows being penalized in the audit functions or? The recommendations right now are only for Reno. There is a todo in the doc= to=20 have a more general recommendation here. Maybe having one for cubic would=20 also make sense. Regarding slow start, in fact all your packets in fight can get lost, right= ?=20 But we assume if in the previous RTT no packets got lost, then number of=20 packets in fight from the previous RTT should be safe to send. Only those=20 packets that we send additionally in this RTT can get lost. In slow start w= e=20 double the packets in flight every RTT, thus we risk to loose half the=20 packets in flight. Is this understandable? May you have some hints how to=20 rewrite this paragraph to make it better understandable!? > > Section 4.3: > One complicating matter in e.g LTE is that the audit function needs to be > in the eNodeB, at handover the audit state will be lost unless it is > communicated to the other eNodeB via the X2 interface. Nothing that needs > mention in this document but it is worth mention anyway. In general it should be no problem if the audit looses the state (what can= =20 also happen because of e.g. re-routing). If the state could be transferred,= I=20 guess that's better. But this such be discussed in=20 draft-kutscher-conex-mobile-03 (cc'ed Dirk).=20 =46or the TCP modification draft there is still this open issue what to do = if=20 the state in the audit is incorrect, e.g. packets when ConEx marks get lost= =2E=20 I guess that's the same case from the perspective of the sender. > > Section 5: > "The sender MUST NOT delay the ConEx signal more than one RTT" : This has > implications for instance for WebRTC as it puts a strict requirement to > feedback the actual congestion information in a timely manner. As of today > the discussion in WebRTC is around feedback of rate request information > rather than congetsion information. Again, nothing that needs to be > mentioned in this doc but should probably be considered if the congetsion > control WG for WebRTC is formed. Very good remark. I monitor Congestion Control for WebRTC and try to keep t= his=20 in mind. > > /Ingemar > > > Nits: > Page 8: "No congestion feedback information are available" --> "No > congestion feedback information is available" > > Page 9: " Thus these packet.." --> " Thus these packets.." > "These packet" --> "These packets" > "unset" --> "reset" ? > > Page 11: "contributed with this.." --> "contributed with his" ? > > > -----Original Message----- > > From: Mirja K=FChlewind [mailto:mirja.kuehlewind@ikr.uni-stuttgart.de] > > Sent: den 10 maj 2012 19:32 > > To: Matt Mathis; Janardhan Iyengar > > Cc: conex@ietf.org > > Subject: [conex] Fwd: New Version Notification for > > draft-ietf-conex-tcp-modifications-02.txt > > > > Hi Matt, hi Jana, > > > > I submitted a new version of the ConEx TCP Mod Draft. I > > believe you volunteered to review the document. > > > > There are currently two ToDos left. One is about a more > > generic description how set the right number of credits > > regarding the congestion control that is used. I think, Matt, > > you had some idea here already. Maybe you can provide some > > feedback here as well. > > The other one is the question if further action needs to be > > take if ConEx markings got lost. I guess I will post this > > question separately on the mailing list. > > > > Thanks in advance, > > Mirja > > > > > > ---------- Forwarded Message ---------- > > > > Subject: New Version Notification for > > draft-ietf-conex-tcp-modifications-02.txt > > Date: Thursday 10 May 2012, 19:26:08 > > From: internet-drafts@ietf.org > > To: mirja.kuehlewind@ikr.uni-stuttgart.de > > CC: rs@netapp.com > > > > A new version of I-D, > > draft-ietf-conex-tcp-modifications-02.txt has been > > successfully submitted by Mirja Kuehlewind and posted to the > > IETF repository. > > > > Filename: draft-ietf-conex-tcp-modifications > > Revision: 02 > > Title: TCP modifications for Congestion Exposure > > Creation date: 2012-05-10 > > WG ID: conex > > Number of pages: 14 > > > > Abstract: > > Congestion Exposure (ConEx) is a mechanism by which senders inform > > the network about the congestion encountered by previous packets on > > the same flow. This document describes the necessary modifications > > to use ConEx with the Transmission Control Protocol (TCP). > > > > > > > > > > > > The IETF Secretariat > > > > ------------------------------------------------------- =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From ingemar.s.johansson@ericsson.com Thu May 24 03:48:45 2012 Return-Path: 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 BB10221F8606 for ; Thu, 24 May 2012 03:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 DvIkyDP7Lz-2 for ; Thu, 24 May 2012 03:48:44 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1691E21F85A3 for ; Thu, 24 May 2012 03:48:43 -0700 (PDT) X-AuditID: c1b4fb2d-b7fac6d000002e89-1d-4fbe120aeab8 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A9.B5.11913.A021EBF4; Thu, 24 May 2012 12:48:43 +0200 (CEST) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.2.32]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 24 May 2012 12:48:42 +0200 From: Ingemar Johansson S To: Mirja Kuehlewind Date: Thu, 24 May 2012 12:48:40 +0200 Thread-Topic: [conex] Fwd: New Version Notification for draft-ietf-conex-tcp-modifications-02.txt Thread-Index: Ac05kXjcidB08J15QwidJlv9AWUrOQAB/eEQ Message-ID: References: <201205101931.30539.mkuehle@ikr.uni-stuttgart.de> <201205241142.00428.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201205241142.00428.mirja.kuehlewind@ikr.uni-stuttgart.de> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+JvrS630D5/gznPeCwOXfvJaPHwUbrF wglvWR2YPZYs+cnkMe/ncWaPGcdesgcwR3HZpKTmZJalFunbJXBlzFr1kb2gw6Hiz9zrzA2M x4y6GDk5JARMJJ52XmWEsMUkLtxbz9bFyMUhJHCKUWLr7hZGCGcBo0Tr+r9sIFVsAjYSKw99 B+sQAbJPdb1nAbGZBfwklq15B2azCKhK3Hv6kx3EFhZIkljS+p4Voj5Z4vK391C9RhKzl10C m8krEC6xfc0nqGUnGIGKpoE1cAq4S0zonAA2iFFAVuL+93tQy8Qlbj2ZzwRxtoDEkj3nmSFs UYmXj/+xQtTLSJxa9J8Vol5P4sbUKWwQtrbEsoWvmSEWC0qcnPmEZQKj2CwkY2chaZmFpGUW kpYFjCyrGIVzEzNz0ssN9VKLMpOLi/Pz9IpTNzECI+rglt+6OxhPnRM5xCjNwaIkzrvZYJe/ kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkaDn1orJe7nx3DftZB5cfUmd9MrtrzYpJVWzq8l sgoFJj+Z51026Xy42kw+c9XSVSHn7RjSoxuYzTUYbki0hBWylXGt5zc+el4mLLik6vKzkrc/ yy9dDM/jnuD/xGi63CwlnUwBG6uF9xeknD17YSdLa9g8vQktRo9i3qdWnvt6SXXyu4TT1Uos xRmJhlrMRcWJAKUoj9Z2AgAA Cc: "conex@ietf.org" Subject: Re: [conex] Fwd: New Version Notification for draft-ietf-conex-tcp-modifications-02.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 10:48:45 -0000 Hi Comments inline where needed. /Ingemar=20 > -----Original Message----- > From: Mirja Kuehlewind [mailto:mirja.kuehlewind@ikr.uni-stuttgart.de]=20 > Sent: den 24 maj 2012 11:42 > To: Ingemar Johansson S > Cc: conex@ietf.org; Dirk Kutscher > Subject: Re: [conex] Fwd: New Version Notification for=20 > draft-ietf-conex-tcp-modifications-02.txt >=20 > Hi Ingemar, >=20 > thanks a lot for your feedback! See some comments inline... >=20 > Mirja >=20 >=20 > On Friday 18 May 2012 15:10:26 Ingemar Johansson S wrote: > > Hi > > > > Thanks for a great effort to get this in order. > > > > Some comments, even though I haven't had the time to follow all the=20 > > details in ConEx I still hope they can be of some value. > > > > I have not scrutinized the computation of CEG and LEG in=20 > detail but I=20 > > follow the discussion and it makes sense. Question, has=20 > anybody done=20 > > any simulation experiments on this ? > Not yet, but it's on my todo list. >=20 > > > > Comments/questions: > > Section 4.1, last sentence: First I did not understand it=20 > at all but I=20 > > believe that I get it now.. Maybe not important but perhaps one can=20 > > rewrite it like The CEG and LEG counters SHOULD be reset if any of=20 > > these conditions > > occur: 1) One RTT since they was last decreased > > 2) One RTT after (loss?) recovery if no further congestion=20 > Not sure if=20 > > this makes things more simple... > Yes, makes sense. I'll rewrite. >=20 > > > > Section 4.2: > > This is IMHO the most complicated part. I fail to=20 > understand why it is=20 > > sufficient with a number of credits which is half the=20 > number of packet=20 > > in flight. Is this some kind of educated estimate ?.=20 > Probably I need=20 > > to get this explained better but there is a chance that=20 > other need it=20 > > too. As regards to the statement that credit marks are only=20 > needed in slow start. > > Cubic's cubic function may make it necessary to add extra=20 > credit marks=20 > > to avoid the flows being penalized in the audit functions or? > The recommendations right now are only for Reno. There is a=20 > todo in the doc to have a more general recommendation here.=20 > Maybe having one for cubic would also make sense. > Regarding slow start, in fact all your packets in fight can=20 > get lost, right?=20 > But we assume if in the previous RTT no packets got lost,=20 > then number of packets in fight from the previous RTT should=20 > be safe to send. Only those packets that we send additionally=20 > in this RTT can get lost. In slow start we double the packets=20 > in flight every RTT, thus we risk to loose half the packets=20 > in flight. Is this understandable? May you have some hints=20 > how to rewrite this paragraph to make it better understandable!? Ahh.. Now I get it!, thanks, sounds very reasonable. Based on your explanat= ion above the text makes sense. Don't have any good suggestion as regards t= o how to improve the text but perhaps if your explanation above can be incl= uded in the text ? (if it is needed). >=20 > > > > Section 4.3: > > One complicating matter in e.g LTE is that the audit=20 > function needs to=20 > > be in the eNodeB, at handover the audit state will be lost=20 > unless it=20 > > is communicated to the other eNodeB via the X2 interface.=20 > Nothing that=20 > > needs mention in this document but it is worth mention anyway. > In general it should be no problem if the audit looses the=20 > state (what can also happen because of e.g. re-routing). If=20 > the state could be transferred, I guess that's better. But=20 > this such be discussed in > draft-kutscher-conex-mobile-03 (cc'ed Dirk).=20 > For the TCP modification draft there is still this open issue=20 > what to do if the state in the audit is incorrect, e.g.=20 > packets when ConEx marks get lost.=20 > I guess that's the same case from the perspective of the sender. Must admit that I have been with my head stuck in the sand for the last cou= ple of months or so, have not had the time to read conex-mobile in detail, = but you are right, something around this probably fits there (unless it is = already mentioned of course) >=20 > > > > Section 5: > > "The sender MUST NOT delay the ConEx signal more than one=20 > RTT" : This=20 > > has implications for instance for WebRTC as it puts a strict=20 > > requirement to feedback the actual congestion information=20 > in a timely=20 > > manner. As of today the discussion in WebRTC is around feedback of=20 > > rate request information rather than congetsion information. Again,=20 > > nothing that needs to be mentioned in this doc but should=20 > probably be=20 > > considered if the congetsion control WG for WebRTC is formed. > Very good remark. I monitor Congestion Control for WebRTC and=20 > try to keep this in mind. Thanks, I will also try to follow the BoF discussion around "congetsion con= trol WG for WebRTC". I am still not sure where ConEx might end up but it is= very relevant for webRTC to consider it. >=20 >=20 > > > > /Ingemar > > > > > > Nits: > > Page 8: "No congestion feedback information are available" --> "No > > congestion feedback information is available" > > > > Page 9: " Thus these packet.." --> " Thus these packets.." > > "These packet" --> "These packets" > > "unset" --> "reset" ? > > > > Page 11: "contributed with this.." --> "contributed with his" ? > > > > > -----Original Message----- > > > From: Mirja K=FChlewind=20 > [mailto:mirja.kuehlewind@ikr.uni-stuttgart.de] > > > Sent: den 10 maj 2012 19:32 > > > To: Matt Mathis; Janardhan Iyengar > > > Cc: conex@ietf.org > > > Subject: [conex] Fwd: New Version Notification for > > > draft-ietf-conex-tcp-modifications-02.txt > > > > > > Hi Matt, hi Jana, > > > > > > I submitted a new version of the ConEx TCP Mod Draft. I > > > believe you volunteered to review the document. > > > > > > There are currently two ToDos left. One is about a more > > > generic description how set the right number of credits > > > regarding the congestion control that is used. I think, Matt, > > > you had some idea here already. Maybe you can provide some > > > feedback here as well. > > > The other one is the question if further action needs to be > > > take if ConEx markings got lost. I guess I will post this > > > question separately on the mailing list. > > > > > > Thanks in advance, > > > Mirja > > > > > > > > > ---------- Forwarded Message ---------- > > > > > > Subject: New Version Notification for > > > draft-ietf-conex-tcp-modifications-02.txt > > > Date: Thursday 10 May 2012, 19:26:08 > > > From: internet-drafts@ietf.org > > > To: mirja.kuehlewind@ikr.uni-stuttgart.de > > > CC: rs@netapp.com > > > > > > A new version of I-D, > > > draft-ietf-conex-tcp-modifications-02.txt has been > > > successfully submitted by Mirja Kuehlewind and posted to the > > > IETF repository. > > > > > > Filename: draft-ietf-conex-tcp-modifications > > > Revision: 02 > > > Title: TCP modifications for Congestion Exposure > > > Creation date: 2012-05-10 > > > WG ID: conex > > > Number of pages: 14 > > > > > > Abstract: > > > Congestion Exposure (ConEx) is a mechanism by which=20 > senders inform > > > the network about the congestion encountered by=20 > previous packets on > > > the same flow. This document describes the necessary=20 > modifications > > > to use ConEx with the Transmission Control Protocol (TCP). > > > > > > > > > > > > > > > > > > The IETF Secretariat > > > > > > ------------------------------------------------------- >=20 >=20 >=20 > --=20 > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany > Pfaffenwaldring 47, D-70569 Stuttgart >=20 > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- > = From ingemar.s.johansson@ericsson.com Thu May 24 11:01:11 2012 Return-Path: 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 3C9ED21F8620 for ; Thu, 24 May 2012 11:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=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 obdSKbJlifkq for ; Thu, 24 May 2012 11:01:10 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id CD78921F85AC for ; Thu, 24 May 2012 11:01:09 -0700 (PDT) X-AuditID: c1b4fb2d-b7fac6d000002e89-8e-4fbe77649f22 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 37.8F.11913.4677EBF4; Thu, 24 May 2012 20:01:08 +0200 (CEST) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.2.32]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 24 May 2012 20:01:08 +0200 From: Ingemar Johansson S To: "conex@ietf.org" Date: Thu, 24 May 2012 20:01:05 +0200 Thread-Topic: ConEx in WebRTC congetsion control Thread-Index: Ac051zBYgophKoPLQT6ADxkO4ijU4g== Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: multipart/alternative; boundary="_000_DBB1DC060375D147AC43F310AD987DCC4D6CABDEBBESESSCMS0366e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+JvrW5K+T5/gw3tVhaHrv1kdGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtaf09kK/ktVXHvYwtLAuFuii5GTQ0LAROLuigWMELaYxIV7 69m6GLk4hAROMUrs+tAM5SxglJg6dRkbSBWbgI3EykPfwTpEBFQllr+8C2RzcLAA2TPWJ4GE hQW0JX5PmcgKUWIgcXxfN1iJiICexItfDiBhXoFwibcvethBbEYBWYn73++xgNjMAuISt57M Z4K4R0BiyZ7zzBC2qMTLx/9YIeplJE4t+s8KUZ8vsbGrhR1ipqDEyZlPWCYwCs1CMmoWkrJZ SMog4noSN6ZOYYOwtSWWLXzNDGHrSsz4d4gFWXwBI/sqRuHcxMyc9HJDvdSizOTi4vw8veLU TYzAaDi45bfuDsZT50QOMUpzsCiJ82422OUvJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbFs w5N9a6PMzMMv5c/nvTLDdktep0fanXaefZrTijT9l2xfc8REtaN61fMHfsczS9fXnOq3WKk7 S9DzEPuklX8LPXJeFLIqt2+sf8Ggdo0p+qiHntTplWkPdHWtmudOKF28V06LgWkTa2rtdd0d f7I285x64HKTzz0we/XVc3VHr/kuM/pnl6fEUpyRaKjFXFScCAD8IQu+VAIAAA== Subject: [conex] ConEx in WebRTC congetsion control X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 18:01:11 -0000 --_000_DBB1DC060375D147AC43F310AD987DCC4D6CABDEBBESESSCMS0366e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi In case you did not know, there is a discussion around ConEx and its releva= nce to WebRTC congetsion control in http://www.alvestrand.no/pipermail/rtp-congestion/2012-May/000375.html /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Senior Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com www.thenodepole.com/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D --_000_DBB1DC060375D147AC43F310AD987DCC4D6CABDEBBESESSCMS0366e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
In case you did not know, there is a discussion around ConEx and its r= elevance to
WebRTC congetsion control in
 
/Ingemar
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Ingemar Johansson  M.Sc. =
Senior Researcher
 
Ericsson AB
Wireless Access Networks
Labratoriegr=E4nd 11
971 28, Lule=E5, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
ingemar.s.johansson@ericsson.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
 
 --_000_DBB1DC060375D147AC43F310AD987DCC4D6CABDEBBESESSCMS0366e_-- From ingemar.s.johansson@ericsson.com Sun May 27 23:15:21 2012 Return-Path: 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 DBD4421F84A6 for ; Sun, 27 May 2012 23:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 uvc2p-H6+p0a for ; Sun, 27 May 2012 23:15:20 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 680CF11E8072 for ; Sun, 27 May 2012 23:15:19 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-bc-4fc317f0cb63 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E9.A1.11869.0F713CF4; Mon, 28 May 2012 08:15:12 +0200 (CEST) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.2.32]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Mon, 28 May 2012 08:15:12 +0200 From: Ingemar Johansson S To: "versteb@cisco.com" Date: Mon, 28 May 2012 08:15:10 +0200 Thread-Topic: [R-C] Effect of ConEx on RMCAT Thread-Index: Ac06XSlCayGmnpnTR5akxX8aBchU1gCOrCsQ Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvre4H8cP+Bp2NxhaHrv1ktFg44S2r xffXrcwWy5c3MzmweFyZcIXVY8rvjaweS5b8ZPKY9/M4cwBLFJdNSmpOZllqkb5dAlfG5sal 7AUPNSqaN61gamB8p9jFyMkhIWAisWXHIyYIW0ziwr31bF2MXBxCAqcYJf5sWsoK4SxglOha swqsik3ARmLloe+MILaIgLbEz19fGEGKmAVuMUpMOL6dFSTBIqAq0bv5MAuILQxUdOD+IzaI Bh2JO9c2AjVwANlGEpeakkDCvALhEg8OfgIrERJwlTjz6APYLk4BN4n+Y+fYQWxGAVmJ+9/v gY1kFhCXuPVkPtTVAhJL9pxnhrBFJV4+/scKUS8jcWrRf1aIeh2JBbsh5jMDnbNs4WtmiL2C EidnPmGZwCg2C8nYWUhaZiFpmYWkZQEjyypG4dzEzJz0ciO91KLM5OLi/Dy94tRNjMAoO7jl t+oOxjvnRA4xSnOwKInzWm/d4y8kkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB0dG6sfdje+48 5/pzeivPXVKZ33i52q/c9tGC/VtYTgSWK1l4/TfcKLPutOgE6fOqGga88XsZGubpL24Smmvh Ij1zSrfzI/17hdtWFSo/dWla7X5a4IX9z2yNxxf61Lcv/mNzU/D57H2fXC8qtxQsXczuUaEg Ofvq7B691KW7Nj9xznriImu3XomlOCPRUIu5qDgRAJv4XkuAAgAA Cc: "rtp-congestion@alvestrand.no" , "conex@ietf.org" Subject: Re: [conex] [R-C] Effect of ConEx on RMCAT X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 06:15:22 -0000 Hi CC the ConEx list as I believe a cross-post is motivated. There has been a few experiments with ConEx, I know Mirja has done some exp= erimentation before, also there was presentation at the last IETF http://tools.ietf.org/agenda/83/slides/slides-83-conex-5.pdf the re-feedbac= k of the ECN marks was however not properly implemented if I remember it ri= ght but the results was anyway interesting.=20 As mentioned in an earier email (from me), I don't believe that ConEx shoul= d be squeezed into the charter now. But what is important is that it should= be recongnized that there are other mechanisms other than the endpoint rat= e adaptation algorithms that benefit from a timely feedback of congestion i= nformation from the receiver back to the sender. /Ingemar =20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Thu, 24 May 2012 09:24:31 -0500 > From: "Bill Ver Steeg (versteb)" > To: "Zaheduzzaman Sarker" , > > Subject: Re: [R-C] Effect of ConEx on RMCAT > Message-ID: > <117602CF2B17DB4F9001427FA6D9053901D19BC6@XMB-RCD-312.cisco.com> > Content-Type: text/plain; charset=3D"iso-8859-1" >=20 > Does anybody have results from trials of ConEX? I have not=20 > seen any. In the absence of such feedback, I am reluctant to=20 > put it on the critical path. It seems like there may be=20 > something good in ConEX, but it does add significant=20 > complexity to the system >=20 > bvs >=20 >=20 > -----Original Message----- > From: rtp-congestion-bounces@alvestrand.no=20 > [mailto:rtp-congestion-bounces@alvestrand.no] On Behalf Of=20 > Zaheduzzaman Sarker > Sent: Thursday, May 24, 2012 7:03 AM > To: rtp-congestion@alvestrand.no > Subject: [R-C] Effect of ConEx on RMCAT >=20 > Hi, >=20 > One topic that so far have not been discussed in this mailing=20 > list is the ConEx and it's effect on congestion avoidance. >=20 > ConEx Background: IETF ConEx WG is chartered here=20 > https://datatracker.ietf.org/wg/conex/charter/. According to=20 > that charter ConEX is working on congestion exposure=20 > mechanism for IPv6 networks. Basically, the receiver of a=20 > flow sends the congestion related information (packetloss,=20 > ECN-CE markings) back to the sender then the sender of the=20 > flow inserts IPv6 header extension to expose that information=20 > to the operators. This is done to aid the congestion=20 > management at the network. Typically as long as the flow does=20 > not exceed a certain congestion volume the network does not=20 > do any kind of traffic shaping on that flow. >=20 >=20 > The effects: >=20 > + RTP media is not ConEx enabled: Bitrate may be throttled > in the network possibly based on some time of day policy or whatever. >=20 > + RTP media is ConEx enabled but no feedback or congestion information > to the sender or congestion feedback is too slow : Audit=20 > functions will find a mismatch between stated and actual=20 > congestion and will start to drop packets. >=20 > + RTP media is ConEx enabled and timely feedback of congestion info to > sender: Packets will pass through unaffected by the ConEx=20 > policers as long as congestion volume quota is not exceeded. >=20 > This means: >=20 > * the operators can drop priority on non-ConEx flows hence a=20 > ConEx enabled flow is treated differently. This will have=20 > impact on the congestion avoidance techniques RMCAT will=20 > produce as same algorithm may not work efficiently enough for=20 > both ConEx enabled flow and non-ConEx enabled flow. >=20 > * a ConEx enabled flow will need to send congestion related=20 > information (perhaps more frequently than usual) i.e. packet=20 > loss and ECN marking information along with simple rate request. >=20 > * RTP media need to be congestion volume aware. >=20 > I see a clear impact on design choice on how to handle these.=20 > I think we should discuss the impact of ConEx here before the=20 > BOF in Vancouver. >=20 > -- > Zahed >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > ANM ZAHEDUZZAMAN SARKER >=20 >=20 > Ericsson AB > Multimedia Technologies (MMT) > Ericsson Research > P.O. Box 920, SE-971 28, Lule?, Sweden > Phone +46 10 717 37 43 > Fax +46 920 996 21 > SMS/MMS +46 76 115 37 43 > zaheduzzaman.sarker@ericsson.com > www.ericsson.com > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > Rtp-congestion mailing list > Rtp-congestion@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtp-congestion >=20 >=20 > ------------------------------ >=20 > _______________________________________________ > Rtp-congestion mailing list > Rtp-congestion@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtp-congestion >=20 >=20 > End of Rtp-congestion Digest, Vol 8, Issue 10 > ********************************************* > =