[e2e] ECN vs SQ: reverse path congestion

[Sally Floyd]

Ratul -

>Reading the thread on ECN vs SQ has made me wonder how does ECN compare to
>SQ when there is congestion on the reverse path. Apart from the 
>comparison, what should the right response be in either case?

The first order of business would be to add congestion control for
pure ACK traffic to TCP even in the environment with only packet
drops, I think.  From the current ECN document at
"http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-01.txt":

>  6.1.4.  Congestion on the ACK-path
>
>   For the current generation of TCP congestion control algorithms, pure
>   acknowledgement packets (e.g., packets that do not contain any accom-
>   panying data) should be sent with the ECT bit off. Current TCP
>   receivers have no mechanisms for reducing traffic on the ACK-path in
>   response to congestion notification.  Mechanisms for responding to
>   congestion on the ACK-path are areas for current and future research.

One proposal for congestion control for ACK traffic is the
internet-draft by Hari Balakrishnan and Venkata N. Padmanabhan in
the pilc working group, at
"http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-pilc-asym-02.txt".
This proposal is based on research from the authors in 1997, so it
is fairly mature.

If we agree that congestion control mechanisms are needed for
pure-ACK traffic even in the case with packet drops, then we should
deal with that first, I would say, instead of evaluating ECN vs.
SQ for current TCP with no such congestion control mechanisms.
Or, that would be my vote.  By itself, my guess would be that ECN
neither fixes the current situation (of congestion on the reverse path)
nor makes it worse, while SQ could in some cases make it worse.

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