Subject: [Tsvwg] RT-ECN concerns

From: [email-masked]
Date: Fri, 5 Aug 2005 05:36:37 -0400

Here's the email I promised (at the tsvwg meeting) regarding concerns
about the RT-ECN proposal (draft-babiarz-tsvwg-rtecn-04.txt).  I suggest
responding to this email by picking out one or a small number of these
issues, and **changing the email subject line**.

Here's a short summary of my concerns:

(1) Probe sequence not good at detecting RFC 3168 ECN implementations.
	There's no reason to believe that a slightly congested 3168 router
	will set a CE value in one of what will typically be two probe
	packets (of the four probe packets, on average, one will have a
	00 ECN value [Not ECT], and one will have a 11 ECN value [CE],
	and hence not be markable with CE).  So the probe sequence will
	likely miss RFC 3168 routers running near/at/over capacity with the
	risk of bad admission decisions if such routers are present.

(2) Probe sequence does not replace function of RFC 3540 nonce.  The
	RT-ECN draft requires that the receiver be trusted, and hence the
	RT-ECN probe mechanism does not detect a cheating receiver that
	fails to return congestion indications to the sender.  Detection
	of such a cheating receiver is the primary purpose of RFC 3540.

(3) RT-ECN's CE(1) -> CE(2) marking is dangerous.  This increase in
	congestion marking for RT-ECN is the same as a CE -> ECT(1) change
	in RFC 3168, enabling an RT-ECN router to erase RFC 3168 ECN
	congestion indications.  If such traffic arrives at a receiver
	that is looking for RFC 3168 indications, this is bad.  At a
	minimum, RT-ECN's CE(1) and CE(2) values ought to be swapped.

(4) Need to look at alternative marking.  At least the admission control
	results in draft-babiarz-rtecn-marking-00.pdf are not a surprise,
	as the odds of 2 packets not getting marked when a router is
	marking only 10% of packets are quite good (81%).  For the
	functionality desired by RT-ECN, having routers switch operation
	among 3 marking modes (using RFC 3168 ECN values) based on
congestion
	should be considered:
		a) Mark no packets (no congestion)
		b) Mark 50% of packets (1st level congestion)
		c) Mark all packets (2nd level congestion)
	If a 4-packet probe sequence of ECT(0) and ECT(1) packets is used,
	the odds of failing to detect a 50%-marking router is 1 in 16
	(about 6%).  In general, marking functions other than the strictly
	linear one tested (mark x% of packets to indicate x% overload)
	should be considered (e.g., if low levels of overload are important,
	ramp marking percentage faster [e.g., 5x ramp would yield 50%
marking
	at 10% overload, after which ramp could be more gentle], or start
	marking at a level other than 0 [e.g., jump to 50% as above]).

I'm starting to wonder whether RT-ECN ought to be an "all routers must
participate" mechanism using something akin to quick start's "TTL in
an option" approach to determine that all involved routers are
participating.  I'd still want to stick with RFC 3168 ECN values even
in such an environment.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

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

---

From: "Fil Dickinson" <[email-masked]>
Date: Tue, 30 Aug 2005 13:55:23 +1000

On Sun, Aug 28, 2005 at 11:18:50AM -0400, Jozef Babiarz wrote:
>> [David's Comment]

>> in such an environment.
>> 
>> [Response]
>> We do not see a reason why all routers must participate in ECN
marking 
>> of real-time traffic. If the router/link is over provisioned so there

>> is no congestion, ECN marking is not needed.
>
> [Ted's point]
>It seems like that's a pretty difficult condition to guarantee from a
router, in general.  Usually congestion control systems assume that they
>don't know where congestion might appear; this makes the design more
difficult, but avoids nasty surprises.

I agree with Ted. 
I don't believe it is cost effective/practical to engineer a network so
that over provisioning eliminates congestion (whether a router supports
a congestion related feature or not). Espescially when considering the
dimension of over provisioning required to cater for some link or node
failures.
I think David's comment should be pursued.

Fil.