Re: [Tsvwg] ECN-based TCP

At 11:59 AM 4/17/02 +0100, Lloyd Wood wrote:

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

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.

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

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?

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

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.

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg