Re: [conex] I-D Action: draft-ietf-conex-tcp-modifications-05.txt

<> Thu, 20 February 2014 11:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 090A61A00D1 for <>; Thu, 20 Feb 2014 03:13:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.699
X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bKLS2PyThZs1 for <>; Thu, 20 Feb 2014 03:13:45 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 97E7E1A00AB for <>; Thu, 20 Feb 2014 03:13:44 -0800 (PST)
Received: from (unknown [xx.xx.xx.1]) by (ESMTP service) with ESMTP id 1A0D518C72F; Thu, 20 Feb 2014 12:13:40 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown []) by (ESMTP service) with ESMTP id F41D335C05A; Thu, 20 Feb 2014 12:13:39 +0100 (CET)
Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Thu, 20 Feb 2014 12:13:39 +0100
From: <>
To: Mirja Kuehlewind <>, "" <>
Thread-Topic: [conex] I-D Action: draft-ietf-conex-tcp-modifications-05.txt
Thread-Index: AQHPKaPkPbfww6plCE6zRkfeaL6dEZq5OcMAgASsbbA=
Date: Thu, 20 Feb 2014 11:13:39 +0000
Message-ID: <2926_1392894820_5305E364_2926_4613_1_2A32CB6629A19041BF4DB7796AD0F5E70A2318DA@PEXCVZYM14.corporate.adroot.infra.ftgroup>
References: <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2014.2.20.100315
Subject: Re: [conex] I-D Action: draft-ietf-conex-tcp-modifications-05.txt
X-Mailman-Version: 2.1.15
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, 20 Feb 2014 11:13:48 -0000


I think there might be a problem with the use of DeliveredData without SACK to increase the CEG. DeliveredData is estimated as follows:

DeliveredData = acked_bytes + SACK_diff + (is_dup)*1SMSS - (is_after_dup)*num_dup*1SMSS

is_dup = 1 if the current ACK is a duplicated ACK
is_after_dup  = 1 for the next full or partial ACK after a number of duplicated ACKs
num_dup counts the number of duplicated ACKs in a row

If a sender loses more than one packet in a row (let's suppose 2 dropped packets), the ACK he will receive from retransmitting the first dropped packet will be a partial ack (if no delayed acks are used or if this segment triggered the ACK). We will then have:
acked_bytes = 1 packet (Only the first retransmitted packet because it didn't fill the whole gap)
SACK_diff = 0 (No SACK used)
is_dup = 0
is_after_dup = 1
num_dup >= 3 packets (Let's suppose 4 duplicate ACKs)

Hence DeliveredData = -3 and the operation CEG += min(SMSS*D, DeliveredData) will decrease the CEG.
When the ACK for the second dropped packet will arrive, it will be a full ACK because it will fill the gap there was. We will then have:
acked_bytes = 5 packets (the second dropped packet + the packets from the 4 duplicate ACKs)
SACK_diff = 0 (No SACK used)
is_dup = 0
is_after_dup = 0
num_dup = 0 packets

Hence DeliveredData = 5 and the operation CEG += min(SMSS*D, DeliveredData) will limit CEG by SMSS*D which should cover the number of CE marks since the last ACK and in our case it shouldn't be more than 1 (in fact in should be 0 since the retransmitted packets mustn't be marked as specified in RFC3168).
When we sum up all the DeliveredData calculated, the result is coherent once we receive the full ACK. DeliveredData then covers all data (-3+5 = 2 retransmitted packets). But because we do the min() operation on every ACK, we may have a negative outcome on a partial ACK which will not be rebalanced on the full ACK and we will potentially lose a number of marks, which could be substantial if the congestion window is big.

We can solve this problem by subtracting num_dup from DeliveredData only on full ACKs. This way, DeliveredData will be positive in every step and the min() operation will not lose potential marks. But there is another case where this solution will lead us to the same problem as before. It's when we have two or more losses in the same window that are noncontiguous. The receipt of the ACK from the first retransmitted packet will give us a positive DeliveredData if we don't subtract num_dup on partial ACKs, but if upon the receipt of the full ACK, the number of acked bytes by this ACK is less than num_dup*SMSS, we will get a negative DeliveredData once again.

We have other solutions that we can apply. We can say that CEG += min(D*SMSS, max(0,DeliveredData)). We don't increase CEG if DeliveredData is negative and hope we can retrieve the cumulative D*SMSS from the next ACK. The ACK triggered from the arrival of a retransmitted packet shouldn't contain a new congestion indication since a retransmitted packet can't be CE marked. It can only contain the congestion marks from the previously received packets.
We can also, upon a partial ACK, subtract from acked_bytes only the number of dups that are between a lost packet and the next lost packet, this number of dups should equal acked_bytes - 1*SMSS (1 for the retransmitted packet).

I hope I didn't misunderstand the use of DeliveredData.

I also have a remark about the credit bits in 4.2. You say that the sender should send as much credits as there are packets in flight. This should avoid sanctions in the auditor side indeed. But if we use a congestion policer and we remove tokens when a credit packet is forwarded as described in draft-ietf-conex-abstract-mech-09, the sender may consume many of his resources by sending credits even if there is no congestion ahead. This is penalizing the sender even though he will not contribute to congestion. I understand that the credits are defined for auditing purposes and it shouldn't rely on the design of the policer used to manage traffic. Nonetheless, policing the senders is what makes ConEx useful.
We can imagine that we may not use the credits in the policer. If we use, in the auditor side, a balance with CE marks in one side and Re-echo and Credit in the other side, this will push the user to send credits rather than re-echo marks to not consume tokens in the policer. The sender will eventually get penalized by the auditor if we use two balances, the first with CE marks and Re-echo marks and the second with CE marks and Credit, but the damage to the network will be done as the auditor should be placed after the potential bottlenecks, and this misbehaving sender will have impacted the other users with his traffic.

With regards,


-----Message d'origine-----
De : conex [] De la part de Mirja Kuehlewind
Envoyé : lundi 17 février 2014 11:56
À :
Objet : Re: [conex] I-D Action: draft-ietf-conex-tcp-modifications-05.txt


we updated the TCP mods draft to comply with the new credit definition. There are lots of changes in sections 3.1.2 (Classic ECN support), 3.2. (Loss
Detection) and 4.2 (Credit Bits). Thus would be great if people would have time to review this version!


On Friday 14 February 2014 17:42:53 wrote:
> 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           : TCP modifications for Congestion Exposure
>         Authors         : Mirja Kuehlewind
>                           Richard Scheffenegger
> 	Filename        : draft-ietf-conex-tcp-modifications-05.txt
> 	Pages           : 14
> 	Date            : 2014-02-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 datatracker status page for this draft is:
> There's also a htmlized version available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at 
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> conex mailing list

Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973

conex mailing list


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,
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, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.