Subject: [tcpm] Adding Acknowledgement Congestion Control to TCP

From: Sally Floyd <[email-masked]>
Date: Fri, 13 Apr 2007 15:35:08 -0700

All -

We have just submitted an internet-draft on "Adding Acknowledgement
Congestion Control to TCP", available from
"http://www.icir.org/floyd/papers/draft-floyd-tcpm-ackcc-00.txt".

This is very much a preliminary investigation, at this stage,
and any feedback would be appreciated.

Abstract:

    This document adds an optional congestion control mechanism for
    acknowledgement traffic (ACKs) to TCP.  The document specifies an
    end-to-end acknowledgement congestion control mechanism for TCP that
    uses participation from both TCP hosts, the TCP data sender and the
    TCP data receiver.  The TCP data sender detects lost and ECN-marked
    ACK packets, and tells the TCP data receiver the ACK Ratio R to use
    to respond to the congestion on the reverse path from the data
    receiver to the data sender.  The TCP data receiver sends roughly one
    ACK packet for every R data packets received.  This mechanism is
    based on the acknowledgement congestion control in DCCP's CCID 2
    [RFC4340], [RFC4341].  This acknowledgement congestion control
    mechanism is being proposed as an experimental mechanism for TCP for
    evaluation by the network community.

Many thanks,
Sally, David, Andres, and Janardhan
http://www.icir.org/floyd/

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: "Armando L. Caro, Jr." <[email-masked]>
Date: Wed, 25 Apr 2007 14:43:14 -0400

I like the idea of attempting to separate forward and reverse path
congestion. I've been thinking about this problem off and on for some
time now, but haven't worked out a detailed solution. In essence, I'd
like for ack losses to not affect throughput on the forward path.
However, I think the motivation of this draft is slightly different. It
seems to be purely motivated by doing proper congestion control in both
directions, right?

Have their been any studies that show that pure acks are a source of
congestion (that we should worry about)? I would expect them to be noise
in the bigger scheme of things. Personally, I have never thought of them
contributing to congestion too much, but have instead been more
concerned with them being affected by the congestion around them.
Asymmetric links (eg, DSL and cable) often see this problem: traffic on
an uncongested downlink gets a performance hit when the uplink becomes
congested. I'm concerned that reducing the number of acks when ack
losses occur is likely to make the problem worse. I would add this issue
to the list of "possible complications".

I realize that this is a preliminary investigation, but has anyone
experimented with this proposal. I'd be interested in seeing the results.

Some other comments:

Re: Section 5.7. Appropriate byte counting allows the cwnd to be
increased by the number of bytes being acked, but there is a cap. Each
ack may increase the cwnd by at most 2*MSS. Thus, an ACK Ratio > 2 will
slow down cwnd growth during slow start. So the text should point to ABC
as guidance, but state that you are now proposing to break that cap and
use rate limiting to mitigate the bursts.

I like the list of possible complications. Except for the one I pointed
out above, I think you hit all the issues I thought of as I read the draft.

Thanks!

-- 
Armando
www.armandocaro.net

---

From: David Ros <[email-masked]>
Date: Fri, 27 Apr 2007 10:40:37 +0200

Le 25 avr. 07 à 20:43, Armando L. Caro, Jr. a écrit :

> congested.

Hi Armando,

Well, my own view is that this would be useful (mostly, but not  
necessarily) in the context of network asymmetry. I'd say that one  
goal of ACK congestion control would be to avoid the "self-inflicted"  
congestion due to ACKs filling up the uplink. There are probably  
other scenarios that I'm missing now where ACK CC could be useful  
but, again, I see network asymmetry as a motivation.

> I'm concerned that reducing the number of acks when ack

Hmm... I must be missing something, I'm not sure I see your point  
clearly.

> experimented with this proposal. I'd be interested in seeing the  

We should start a simulation study Really Soon Now (Andrés is  
currently coding the stuff in ns-2).

Thanks a lot for the feedback!

David.