Subject: [Tsvwg] RT-ECN and detection of 3168 routers

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

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

[Response] 
After reviewing what we wrote in version 4 of the RT-ECN draft and the
above question, we need to clarify the procedure of how inappropriate
changes to ECN marking is detected, before and after the flow is
admitted.

Let me explain the sequence of events. 
Before the flow is admitted, the purpose for the first random sequence
of the four possible ECN bit combinations is not intended to detect
presence of RFC 3168 capable routers.  But is to verify that no device
in the path sets ECN bits to a single state, "10" etc. and to verify
that ECN states are copied correctly when tunneling, etc. 

After the sequence of the first four RTP-probe packets, RTP-probe
packets are sent with random marking of 10, 11 and 01. This probe flow
is performed until the call is answered and this is the probe flow the
end system looks at for admission control. After taking a second look,
it probably is better if we randomly send only ECN 10, 01. Since during
the flow admission phase (call setup until call is answered), probing is
performed for a relatively short time (few seconds), it may not detect
congested 3168 router in the path but should a router mark a packet that
has ECN 01 to 11 CE than it will be detected before the actual media
flow is started. We were planning to provide the detail description of
the probing sequences in the RTECN-Use-Case draft.

Once a flow is admitted and media flow has started, we use the following
mechanism for detection of congested 3168 routers: Media packets are
sent with random setting of ECN 10 and 01. The current proposed method
sends approximately 12 out of 50 packets marked with ECN 01 per second
(assuming G.711 codec at 20ms). Packets marked with ECN 01 are used for
detection of 3168 routers because should a congested 3168 router set
packet marked with 01 to 11 (CE), the RT-ECN compliant receiver would
detect that this flow is not conformant and terminate the session. The
issue of how quickly will 3168 routers be detected is a function of
congestion level and marking algorithm of RFC 3168 router. 

Question, does the detection take too long? 

We believe that should RT-ECN traffic encounter router that uses 3168
marking it will not push-out or harm TCP traffic as prolonged congestion
would cause RT-ECN traffic to be preempted (terminated). We think this
would be OK since the flow is not increasing its rate and will be
removed after a period of time.

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

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