Subject: RE: [Tsvwg] RT-ECN concerns

From: "Jozef Babiarz" <[email-masked]>
Date: Sun, 28 Aug 2005 11:18:50 -0400

Thank you David for your analysis and suggestions.

Sorry for the delay in responding to David's concerns.  There was
personal vacation after the Paris meeting.  Also, we wanted to consider
David's concerns carefully.  At current time, we still have not come to
conclusions wrt which method for marking may be better.  Hence some of
the responses may be in the form of questions to encourage discussion on
the list.

We split the detail responses to each of David's 4 concerns into their
own E-Mail discussion threads, as David suggested.  Please see them on
the list.

For David's comments at the bottom of his E-Mail, we are addressing it
here:

[David's Comment]
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.

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

Regards,
-- Joe Babiarz, Kwok Ho Chan, Corey Alexander -

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Friday, August 05, 2005 5:37 AM
To: [email-masked]
Subject: [Tsvwg] RT-ECN concerns

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

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

---

From: Ted Faber <[email-masked]>
Date: Mon, 29 Aug 2005 12:03:25 -0700

> no congestion, ECN marking is not needed.

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.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg