Subject: [Tsvwg] ECN-based TCP

From: Liaw Yong Shyang <[email-masked]>
Date: Wed, 17 Apr 2002 14:08:56 +0800

Hi,

I have been looking at the problem of TCP over lossy wireless network for 
sometimes, and I would appreciate if you can comment on the following.  If 
you need more information, please feel free to contact me.  Thank you.

=====================

The main problem of TCP over wireless is that it cannot differentiate the 
type of losses (i.e. congestive or bad channel), and TCP indiscriminately 
invokes congestion control whenever losses occur.  Since ECN provides a 
mechanism for network routers to signal congestion to the end hosts, TCP 
can rely on ECN as congestion indication (i.e. ECN-based TCP), thereby is 
able to differentiate the type of losses.  This allows TCP to reduce its 
sending rate only when ECN indicates congestion during Fast Retransmit, and 
avoid unnecessary reduction.  I have simulation results to show that this 
greatly enhances TCP performance over wireless link under various network 
conditions.

Of course, the above assumes that all the network routers support ECN, and 
this is not realistic.  I expect that over the next 10 - 15 years, ECN will 
be widely implemented in the network router and deployed in the 
network.  However, we can expect that over this period of gradual 
deployment, there will be some old routers that are not ECN-enabled in the 
network.  Therefore, there is a need to determine whether all the routers 
along the path taken by a TCP connection is ECN-enabled.  And ECN-based TCP 
(i.e. only ECN is taken a congestion signal) is used only when the path is 
ECN-enable, otherwise losses shall be taken as sign of congestion as in the 
traditional TCP.  I would like to extend ECN to provide this capability, so 
that TCP can negotiate whether to rely on ECN only, or  both ECN and losses 
as congestion signal.  This can be done by providing a 8-bit "ECN-counter" 
field in the IP header (i.e. as IP option).  The "ECN-counter" shall be 
treated just the same as the "Time-to-live" field in the IP header -- 
decrement by one on passing each ECN-enable router along the path.  On 
reaching the destinated end-host, if "ecn-counter" equals the 
"time-to-live" field, then we can conclude the path is ECN-enabled, and the 
end-host will inform the TCP sender.

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

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 17 Apr 2002 11:59:32 +0100 (BST)

On Wed, 17 Apr 2002, Liaw Yong Shyang wrote:

> avoid unnecessary reduction.

ECN is an imperfect measure of congestion; packets marked with an ECN
bit are themselves subject to congestion. If you receive a packet
marked with an ECN bit (and it really is an ECN bit rather than some
old-style QoS marking...) you know there's congestion in your path,
but if you don't you can't be sure (because the packet might be lost).
So, TCP can never expect to rely only on ECN. (In IPv6 there's no
header checksum -- so can you really trust the ECN bit you see?)

The ECN counter as an IP header option would require *large* amounts
of router processing, as packets with options are not handled on a
fast path or in hardware. And if path rerouting occurs during a
TCP session or you have split paths...

TCP negotiation's in RFC3168 section 6; splits paths are further down.

cheers,

L.

>  I have simulation results to show that this

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Randall Stewart <[email-masked]>
Date: Wed, 17 Apr 2002 06:41:32 -0500

Liaw:

A thought for you to consider... just because a router
is capable of ECN does NOT mean it will always ONLY use
ECN to indicate congestion. A router will keep different
thresholds... the first one will be where it starts marking
packets... but if congestion continues it will start dropping
packets..

Basically you can NOT rely on ECN by itself so that you can
tell the difference between a drop due to error and a drop
due to congestion... IMO... Sally what do you think?

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: Liaw Yong Shyang <[email-masked]>
Date: Thu, 18 Apr 2002 11:03:25 +0800

>but if you don't you can't be sure (because the packet might be lost).

Yes, packets can be lost due to buffer over-flow, or along the path to 
destination.
To make ECN more robust to losses, we can do the followings:
a. mark more packets (i.e. higher marking probability near the maxthresh) 
-- this shall aid against marked packet loss along the path.
b. use timeout as congestion indication (as a backup), and reset cwnd to 
1  (as in traditional TCP). -- this shall help to capture persistent 
congestion in the router.

With occasional losses, I think it is not a problem.

>header checksum -- so can you really trust the ECN bit you see?)

Yes this is a problem, and I haven't really think much about the security 
aspect.  What about the "ECN-nonce" proposed in the Internet draft "Robust 
ECN Signaling with Nonces" at 
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-nonce-02.txt?  Can 
that help?

>TCP session or you have split paths...

Yes, IP option is not a nice thing, but there is no more space in the IP 
header.  For IPv6, it can be an IPv6 header extension.  Actually, it is not 
necessary to send "ecn-counter" option in every packets all the time.  We 
may send the option on packets for the 1st few windows to determine that 
the paths taken (including multi-paths) are ECN-capable, and then every few 
other windows regularly -- assuming that paths will not changes too frequently.

>TCP negotiation's in RFC3168 section 6; splits paths are further down.

OK, I will take a look at it.  Thank.

---

From: Liaw Yong Shyang <[email-masked]>
Date: Thu, 18 Apr 2002 13:51:45 +0800

Hi Randall & Sally,

Thank for your reply.

In the current ECN (RFC 3168), RED AQM will drop packet once it exceeds 
maxthresh -- this is designed to use loss as an indication of 
congestion.  In the case where ECN is to be used as the only congestion 
indication, the packets shall be marked instead of being dropped.  Of 
course when the buffer is full, packets will still be dropped.

I think, to take ECN  as the only congestion indication, there must have 
some supports from the router':
- mark-tail, instead of drop tail (for ECT packets)
- provide "sufficient" buffer so that TCP packets are marked once beyond 
maxthresh
- perhaps, mark more packets (higher marking probability) especially when 
it is near maxthresh, may be the Adaptive RED -- help to be robust against 
loss along the path.

Additionally, TCP must also have timeout mechanism as a backup, in case 
ECN-marked packet are lost along the path, and buffer-overflow in router.

I have done some work on this, and have written up a paper (accepted for 
WOC2002) -- I am on the process of setting up my web-page, and will inform 
you once it is up (soon).  In this, I showed that it is possible to keep 
ECN-based TCP not more "aggressive" than traditional TCP/SACK during 
congestion.

Further improvements may be done.  For example, fine-tuning the level of 
congestion according to the amount of marked packets received.  Say if 50% 
of the packets received are marked, then TCP sender shall consider more 
drastic action then just halve the cwnd (i.e. reset cwnd to 1).

Thanks.

---

From: Liaw Yong Shyang <[email-masked]>
Date: Thu, 18 Apr 2002 15:15:58 +0800

Hi Randall & Sally,

My paper  "Decoupling of TCP Congestion Control and Loss Recovery for 
Wireless Network" can be found at http://www.cwc.nus.edu.sg/~liawys/.  Thanks.

---

From: "Elia Chen" <[email-masked]>
Date: Thu, 18 Apr 2002 17:58:34 +0800

----- Original Message ----- 
From: "Liaw Yong Shyang" <[email-masked]>
To: "Lloyd Wood" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, April 18, 2002 11:03 AM
Subject: Re: [Tsvwg] ECN-based TCP

> With occasional losses, I think it is not a problem.

Hello Shyang,

Your solution b is still a question for improving the perfomance issue in
the error-prone link environment. Under the situation of both frequent 
drops and occassional errors to packets, what should the sender react?

Indeed, only ECN is not perfect, as Lloyd said. The reason is on the
difficulty to distinguish path congested or not congested, in the situation 
mentioned above. While receiver got less packets, it got less ECN bits.

Randall and Sally just reminded that packet losses is still the primary 
signal for congestion. However, this conclusion is not a good news. >_<

I've ever seen a special approach to apply the ECN mark to wireless
networking. It uses the context by ECN marks and loss as the congestion
coherence. You can find it at Raj Jain's web page:

http://www.cis.ohio-state.edu/~jain/papers.html

Wish it can do some help to you, and good luck. ^_^

--
Shi-Yang Elia Chen <[email-masked]>

---

From: Liaw Yong Shyang <[email-masked]>
Date: Fri, 19 Apr 2002 10:40:05 +0800

Hi Elia,

>drops and occassional errors to packets, what should the sender react?

First, let me thank for your comment.

Solution b (timeout) is not mean to improve the performance, but to capture 
the persistent congestion and invoke congestion control since congestion 
(buffer overflowing) at the router will drop packets.  So performance is 
improved only when there is bit-error losses, and network is not heavily 
congested.  When packets are dropped due to congestion, the sender will 
retransmit and go into fast recovery mode.  There are 3 possible cases here:
a) if the congestion persists, the retransmit pkt will be dropped, and 
eventually TCP will timeout, and reset cwnd to 1.
b) if the congestion subsides, but still above maxthreash, the retransmit 
pkt will be marked, and hence eventually sender will invoke congestion control.
c) if the congestion has subsides, and hence the packet is not marked, then 
TCP sender shall continue from where it was before the pkt was dropped.

>signal for congestion. However, this conclusion is not a good news. >_<

I agree with you and the rest (Lloyd, Randall and Sally) that I cannot rely 
on ECN as the only congestion indication.  This is especially so when the 
network is heavily congested, and when the link BER is very "high", which 
will result in substantially increase in the packet loss rate.  Perhaps, it 
is OK to rely on ECN only when network is not heavily congested (i.e. the 
loss rate is below certain threshold), and when TCP receiver sees a 
significant increase in packet loss, it shall indicate ECE in its ACK to 
the sender.

>coherence. You can find it at Raj Jain's web page:

Would it have the same problem, as packets may just get dropped instead, 
and marked packet may be lost along the path?