Subject: RE: [NSIS] Re: [Tsvwg] Re: additions on draft-floyd-ecn-alternate s-02.txt

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 24 Nov 2005 09:18:34 +0100

Hi Phil,

some more thoughts in line.

Regards, Rüdiger

[snip]

|My personal view is:
|
|- The way you apply ECN within the backbone seems
|  to be conforming to the aims of ECN. There in
|  fact is a congestion of the specific resource
|  identified by a packets DSCP.
|
|[phil] note that ECN marking is used as a notification
|of pre-congestion (compare point above)

[Rudi] that might be a philosophical question. The ECN 
marking informs a router that no more sessions should 
be admitted / the traffic on a link needs to be 
throttled. Isn't that the purpose of ECN too?

CL resources may be dimensioned to carry traffic of 
another link without causing CL losses and leave space 
for other services. In my eyes, that's a clear benefit, 
as it allows for network based flow control of elastic 
and inelastic traffic in the same network. Admission 
control is an important part of inelastic flow control.

|
|- I personally may prefer the ECN field remaining
|  unchanged, once congestion is indicated. 
|
|[phil] if you mean remain unchanged when the pkt travels 
|outside the Diffserv domain (termed CL-domain in the i-d), 
|then i disagree. in the CL-domain the ECN marking is used for 
|adm ctrl purposes. the usage foreseen in RFC3168 is for active 
|queue mgt. this leads to different algorithm for setting the 
|CE codepoint. 

[Rudi] Good point. I made an assumption which I didn't mention. 
I assume a signaling/reservation based admission control 
outside the DiffServ region. This should avoid congestion and 
the set ECN bits shouldn't cause any harm there.

|Wouldn't
|  this make your proposed architecture ECN conformant?
|
|[phil] we believe it's already conformant with rfc3168. since 
|the ce codepoint is used to indicate incipient congestion. the 
|algorithm for deciding whether to set it isnt RED, but this 
|isnt in conflict with rfc3168. (The key difference is that RED 
|looks at the length of the real queue, whereas our algorithm 
|looks at the length of a virtual queue - the latter is emptied 
|at a slower rate than the real queue, so the ce codepoint is 
|set before the length of the real queue has started to increase.)

[Rudi] I agree. All I asked is whether re-writing the ECN bits 
is ECN conformant.

|  Further, capable end-systems could renegotiate
|  Codecs.
|
|
|[phil] as bob says, if the end-to-end ecn information is 
|really needed inside an end-to-end reservation, then the info 
|can be delivered through the signalling across the CL-domain 
|(not that i'm yet convinced that's needed) - and then your 
|codec renegotiation can still happen.

[Rudi] Yes, sure. I don't build routers and if the people doing 
it say "the router inspects all the packets anyway, adding the 
ECN evaluation and triggering a new signaling message doesn't 
add significant processing load", I'm convinced of Bob's point. 
Otherwise, the end system should be involved. 

Regards,

Rüdiger

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