Subject: Re: Any SPs using QoS ???

From: Curtis Villamizar <[email-masked]>
Date: Fri, 06 Oct 2000 12:40:28 -0400

In message <5.0.0.25.2.20000929150628.0274b540@flipper>, Fred Baker writes:
> At 01:08 PM 9/28/00 -0700, Randy Bush wrote:
> >this has appeal.  but ecn looks much simpler.
> 
> Is ECN something that you would consider pushing toward standardization? I 
> like it, but I'm looking for operator feedback, and some (notably Juha) 
> distrust a mechanism that trusts the host.

It should at least go through as experimental but preferably as
proposed standard.  Shouldn't the ECN WG get Cc'd?

Curtis

ps - Juha doesn't have to turn it on if he doesn't trust it.

---

From: Ping Pan <[email-masked]>
Date: Fri, 06 Oct 2000 14:12:09 -0400

> ps - Juha doesn't have to turn it on if he doesn't trust it.

Please educate me here. Is the idea of ENC similar to that of FECN and
BECN in Frame Relay? That is, upon congestion notification, end nodes
start to slow down packet transmission. Many routers today happen to be
the "end nodes". They generally use GRE encapsulation to support user's
traffic (such as delay-sensitive SNA data). Supporting ECN would mean
that the edge routers must (re)implement congestion avoidance mechanism
for encapsulated packets, is that correct? Do you think this may cause
deployment problem? Or maybe all routers have such capability already.

--
Ping Pan         http://www.cs.columbia.edu/~pingpan

---

From: Fred Baker <[email-masked]>
Date: Fri, 06 Oct 2000 17:13:47 -0700

>proposed standard.  Shouldn't the ECN WG get Cc'd?

it *is* experimental. I think the argument is towards PS

---

From: Fred Baker <[email-masked]>
Date: Fri, 06 Oct 2000 17:15:28 -0700

it means that under configuration control the routers should implement RED 
not only by dropping, but by marking traffic, and end hosts should do 
certain things including responding to the mark in a congestion avoiding manner.

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 16 Oct 2000 11:36:21 -0400

> deployment problem? Or maybe all routers have such capability already.

ECN is not like FECN and BECN.  ECN is used for end-to-end congestion
avoidance (TCP).  The ECN ECT (ECN capable transport) bit is used to
indicate that the end systems are ECN capable and using ECN.  The CE
(congestion experienced) bit is set by routers in place of a drop to
indicate that a drop would have occurred.  TCP is expected to react as
if a drop has ocurred, but the retransmission is avoided.

Discussions of how to penalize hosts that fake ECT and then don't back
off is a lengthy topic.

Curtis

---

From: Fred Baker <[email-masked]>
Date: Wed, 18 Oct 2000 19:25:33 -0700

>if a drop has ocurred, but the retransmission is avoided.

Actually, I would argue that it is a lot like FECN. The model for FECN 
(proposed by Goldstein as I recall) was that it would be received by a 
Frame Relay DTE, and be copied into an option in CLNS. CLNS would then 
deliver it to the receiving TP-4, which would implement the DEC Bit 
algorithm to attempt to adapt transmission rate to the knee (as opposed to 
the cliff) of the power curve.

In the ECN case, we have a network layer protocol rather than a link layer 
protocol, but again the idea is that congestion would be sensed en route 
and reported by the network layer (IP) to the receiving transport (TCP), 
which would take very similar actions to accomplish the same goal.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 18 Oct 2000 17:47:40 -0400

> the cliff) of the power curve.

DECBIT worked terribly.  Are you arguing that IP ECN is like FECN only
it works?

> which would take very similar actions to accomplish the same goal.

The link layer was intended to be edge to edge, not end to end.  This
is the major difference and the reason that MPLS LSRs should not try
to somehow spoof ECN.

Curtis

ps - I think we're off topic for MPLS.  IMHO Experimental is fine for
now, though Randy seems to disagree.