Subject: Re: [tcpm] Adding Acknowledgement Congestion Control to TCP

From: Janardhan Iyengar <[email-masked]>
Date: Tue, 01 May 2007 22:04:18 -0400

Hey Armando,

(Sorry about the long delay!)

> 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

I don't think that matters really. If a link is congested, then all 
flows through it should respond to congestion signals. Even if the 
'flow' is an ack flow. IMHO, that is the motivation for ack CC.

 > 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

On the contrary, it seems to me that reducing the number of acks when 
the uplink is unable to handle as many acks is a GOOD thing. If the 
uplink is unable to handle the current ack rate, then ack CC will reduce 
the ack rate so that congestion on the ack path and ack loss will be 
reduced.

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

Good catch. Thanks!

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

Great!

Thanks for the feedback!
- jana

-- 
Janardhan R. Iyengar
Visiting Assistant Professor
Connecticut College
http://cs.conncoll.edu/iyengar/

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

---

From: Sally Floyd <[email-masked]>
Date: Mon, 14 May 2007 04:49:39 -0700

Armando -

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

(My apologies for the delayed response to this.)

Yep, the draft is largely motivated by the desire to do proper
congestion control in both directions.  To the extent that proper
congestion control can *reduce* packet drop rates for ack packets
as well as for other traffic sharing the path, this should also
help TCP performance over paths that have congestion on the return
path.  And one of the goals is to try to implement Ack Congestion
Control (AckCC) in a way that has a minimal negative impact on the
performance of that TCP connection even for the case where the AckCC
doesn't make any change in the packet drop rates for the ack packets.

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

I don't know of any studies off-hand, and I certainly don't think
of congestion caused by pure ack packets as one of the pressing
problems of the current Internet.  But there are plenty of TCP
connections where ack packets are dropped, and plenty of different
kinds of congestion.

E.g., on a congested link where the limitation is the bandwidth in
bits per second, there could be a congested queue (either a Drop-Tail
queue in units of packets, or Active Queue Management in packet
mode) where small ack packets take as much space in the queue as
large data packets, and where a third of the packets in the queue
are small ack packets (as would be the case on a link carrying
balanced bi-directional data traffic).  And in this case, using
AckCC *could* reduce packet drop rates in the congested queue even
though it doesn't substantially reduce the load in terms of bytes
per second.

Or there could be paths where the limitation is in router CPU
cycles in packets per second rather than in bandwidth in bits per
second.  In this case, AckCC could reduce the load on the
congested router.

> 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
> to the list of "possible complications".

I agree that it would be good to add, as a "possible complication",
the case where the packet drop rate for the ack traffic is relatively
fixed (e.g., caused by competing UDP traffic), and the use of AckCC
might make the performance of the TCP connection even worse that
it would be without AckCC.  Hopefully even in this case, the use
of AckCC won't have a significant negative impact of the performance
of the TCP connection.

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

Thanks, we will add this.

> out above, I think you hit all the issues I thought of as I read the 

Many thanks for the feedback!

- Sally
http://www.icir.org/floyd/