From: <ali.sanhaji@orange.com>
To: Mirja Kuehlewind <mirja.kuehlewind@ikr.uni-stuttgart.de>,
 "conex@ietf.org" <conex@ietf.org>
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: <20140214164253.28397.10349.idtracker@ietfa.amsl.com>
 <201402171156.26472.mirja.kuehlewind@ikr.uni-stuttgart.de>
In-Reply-To: <201402171156.26472.mirja.kuehlewind@ikr.uni-stuttgart.de>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/conex/qrRd77WuFPzKUPej2ZVZvTGSahw
Subject: Re: [conex] I-D Action: draft-ietf-conex-tcp-modifications-05.txt
Precedence: list

Hi,

I think there might be a problem with the use of DeliveredData without SACK=
 to increase the CEG. DeliveredData is estimated as follows:

DeliveredData =3D acked_bytes + SACK_diff + (is_dup)*1SMSS - (is_after_dup)=
*num_dup*1SMSS

is_dup =3D 1 if the current ACK is a duplicated ACK
is_after_dup  =3D 1 for the next full or partial ACK after a number of dupl=
icated 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 pa=
ckets), the ACK he will receive from retransmitting the first dropped packe=
t will be a partial ack (if no delayed acks are used or if this segment tri=
ggered the ACK). We will then have:
acked_bytes =3D 1 packet (Only the first retransmitted packet because it di=
dn't fill the whole gap)
SACK_diff =3D 0 (No SACK used)
is_dup =3D 0
is_after_dup =3D 1
num_dup >=3D 3 packets (Let's suppose 4 duplicate ACKs)

Hence DeliveredData =3D -3 and the operation CEG +=3D min(SMSS*D, Delivered=
Data) will decrease the CEG.
When the ACK for the second dropped packet will arrive, it will be a full A=
CK because it will fill the gap there was. We will then have:
acked_bytes =3D 5 packets (the second dropped packet + the packets from the=
 4 duplicate ACKs)
SACK_diff =3D 0 (No SACK used)
is_dup =3D 0
is_after_dup =3D 0
num_dup =3D 0 packets

Hence DeliveredData =3D 5 and the operation CEG +=3D min(SMSS*D, DeliveredD=
ata) will limit CEG by SMSS*D which should cover the number of CE marks sin=
ce the last ACK and in our case it shouldn't be more than 1 (in fact in sho=
uld 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 onc=
e we receive the full ACK. DeliveredData then covers all data (-3+5 =3D 2 r=
etransmitted 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 rebalance=
d on the full ACK and we will potentially lose a number of marks, which cou=
ld 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 wh=
ere 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 rece=
ipt 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 tha=
n num_dup*SMSS, we will get a negative DeliveredData once again.

We have other solutions that we can apply. We can say that CEG +=3D min(D*S=
MSS, max(0,DeliveredData)). We don't increase CEG if DeliveredData is negat=
ive and hope we can retrieve the cumulative D*SMSS from the next ACK. The A=
CK 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 pack=
ets.
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 numbe=
r 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 avo=
id 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 dra=
ft-ietf-conex-abstract-mech-09, the sender may consume many of his resource=
s by sending credits even if there is no congestion ahead. This is penalizi=
ng the sender even though he will not contribute to congestion. I understan=
d 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, i=
n the auditor side, a balance with CE marks in one side and Re-echo and Cre=
dit 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 eventua=
lly 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 da=
mage to the network will be done as the auditor should be placed after the =
potential bottlenecks, and this misbehaving sender will have impacted the o=
ther users with his traffic.

With regards,

Ali

-----Message d'origine-----
De=A0: conex [mailto:conex-bounces@ietf.org] De la part de Mirja Kuehlewind
Envoy=E9=A0: lundi 17 f=E9vrier 2014 11:56
=C0=A0: conex@ietf.org
Objet=A0: Re: [conex] I-D Action: draft-ietf-conex-tcp-modifications-05.txt

Hi,

we updated the TCP mods draft to comply with the new credit definition. The=
re 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!

Thanks,
Mirja


On Friday 14 February 2014 17:42:53 internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts=20
> directories. This draft is a work item of the Congestion Exposure=20
> 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:
> https://datatracker.ietf.org/doc/draft-ietf-conex-tcp-modifications/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-conex-tcp-modifications-05
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-conex-tcp-modifications-05
>
>
> Please note that it may take a couple of minutes from the time of=20
> submission until the htmlized version and diff are available at=20
> tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> conex mailing list
> conex@ietf.org
> https://www.ietf.org/mailman/listinfo/conex



--
-------------------------------------------------------------------
Dipl.-Ing. Mirja K=FChlewind
Institute of Communication Networks and Computer Engineering (IKR) Universi=
ty 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
-------------------------------------------------------------------

_______________________________________________
conex mailing list
conex@ietf.org
https://www.ietf.org/mailman/listinfo/conex

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.