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

From: [email-masked]
Date: Fri, 14 Feb 2014 08:42:53 -0800

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:
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=draft-ietf-conex-tcp-modifications-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 17 Feb 2014 11:56:26 +0100

Hi,

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!

Thanks,
Mirja

On Friday 14 February 2014 17:42:53 [email-masked] 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.
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex

-- 
-------------------------------------------------------------------
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
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

---

From: <[email-masked]>
Date: Thu, 20 Feb 2014 11:13:39 +0000

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 = 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,

Ali

-----Message d'origine-----
De : conex [mailto:[email-masked]] De la part de Mirja Kuehlewind
Envoyé : lundi 17 février 2014 11:56
À : [email-masked]
Objet : 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. 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!

Thanks,
Mirja

On Friday 14 February 2014 17:42:53 [email-masked] wrote:
> directories. This draft is a work item of the Congestion Exposure 
> Working Group of the IETF.
>

--
-------------------------------------------------------------------
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

_________________________________________________________________________________________________________________________

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.