Subject: RE: ECN [was Re: [Diffserv] Comment on model draft-03]

From: Andrew Smith <[email-masked]>
Date: Thu, 1 Jun 2000 11:56:31 -0700

I think the right approach for now would be for someone who is up with the
ECN work to look at the current Model draft and let us know where, if
anywhere, some changes might be needed to fit it into the model. We don't
need the ECN components in the Model draft right now but it would be good to
check that we have sufficient hooks to allow it at a later date.

Andrew

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Thursday, June 01, 2000 11:28 AM
> To: jamal
> Cc: [email-masked]
> Subject: ECN [was Re: [Diffserv] Comment on model draft-03]
> 
> 
> jamal wrote:
> > 
> > On Tue, 30 May 2000, Brian E Carpenter wrote:
> ...
> > > > With the algorithmic dropper,since you use the RED-like 
> algorithm as
> > > > an example, where does ECN marking fit? (note your 
> usage of "dropper").
> > >
> > > ECN isn't part of Diffserv, so it doesn't fit in anywhere.
> > >
> > 
> > Great; so now Diffserv lives in an isolated world. I 
> thought you said that
> > you cant avoid implementation specifics in some cases. I 
> know you are
> > trying to close this document but ...
> > Both ECN and Diffserv use RED and some of "marking" the old 
> 8bits. That is
> > a bit too close to hand wave away.
> > I see the use of the ECN bits for example being used to 
> provide a lossless
> > AF end2end service for TCP.
> 
> ECN is an Experimental Protocol (RFC 2481). We can't build 
> any dependency
> on it in a standards track activity. (Agreed, the diffserv 
> conceptual model
> is not a standards track document, but the diffserv MIB is.) 
> If the ECN
> community wants to write a Conceptual Model for ECN-enabled 
> Routers they
> are more than free to do so; I don't see any conflict between ECN and
> diffserv, but I don't see any required relationship either. 
> 
> I certainly agree that in an implementation, I would expect 
> the ECN marker
> to be closely associated with a dropper. But that's a product issue.
> 
>    Brian
> 
> 
> > 
> > > > Another rat hole.
> > > > Out of band smoothing function versus in-data-path 
> smoothing function.
> > >
> > > Doesn't look out of band to me; there's a feedback loop 
> right there.
> > 
> > I should have been more specific:
> > with the abovce scheme you periodically sample the queue 
> and compute the
> > RED paramaters offline on the control plane (as in not in the data
> > path). I refer to this as out of band. Some other scheme 
> might compute
> > things per packet on the data path; this would be inband.
> > 
> > cheers,
> > jamal
> 
> -- 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Brian E Carpenter 
> Program Director, Internet Standards & Technology, IBM 
> On assignment for IBM at http://www.iCAIR.org 
> Attend INET 2000: http://www.isoc.org/inet2000
> Non-IBM email: [email-masked]
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: jamal <[email-masked]>
Date: Sat, 3 Jun 2000 11:07:11 -0400 (EDT)

> check that we have sufficient hooks to allow it at a later date.

To Brian:
Indeed there are plans to move ECN to proposed standard.
cc-ed [email-masked]
[OOT: I noticed you are at Iband; attend Jerome Tassel's talk
on congestion based pricing " ECN instead of Diffserv" ;->]

Andrew, I have been keeping up with ECN; unfortunately i dont see an easy
way to change the draft with terms like algorithmic "dropper" so deeply
embedded into the definition. ECN also uses the term "marking" to mean
marking the Congestion experienced bit (not the DSCP).

The above can be worked around if we could agree on adding to figure 5 
"discard decision" box preceeding "discard" . I could then provide
you with the appropriate text. New diagram would look like:

           +------------------+      +-----------+
           | +-------+        |  n   |smoothing  |
           | |trigger|<----------/---|function(s)|
           | |calc.  |        |      |(optional) |
           | +-------+        |      +-----------+
           |     |            |              ^
           |     v            |              |Depth
  Input    | +---------+    +-------+  no  -----------+   to Scheduler
  ---------->|         |--> |discard|----->   |x|x|x|x|------->
           | | discard |    |   ?   |       ----------+
           | | decision|    +---|---+             FIFO
           | +----------       yes            
           |                    |             
           |                  | v |           
           |                  +   + count +   
           |                  +---+ bit-bucket
           +------------------+
           Algorithmic
           Dropper

The diagram could look better ;->

Note: the discard decision box will not only worry about whether to
mark the CE bit but also take care of misplaced things like which packet
to drop (front, tail etc).

cheers,
jamal

---

From: Fred Baker <[email-masked]>
Date: Sat, 03 Jun 2000 08:32:22 -0700

>marking the Congestion experienced bit (not the DSCP).

when I used the word in the definition, that was what was in my mind. Would 
you care to offer alternative language that would make this more clear?

---

From: "K. K. Ramakrishnan" <[email-masked]>
Date: Sat, 3 Jun 2000 12:48:21 -0400

It seems to me that you want to have a decision making function that "selects"
a packet. Subsequently, you may "drop" or "mark" or treat the packet in some
distinctive manner.
Would it be appropriate to refer to the function as a packet "selection"
function, instead of "dropper"?
 K. K. Ramakrishnan

-- 
K. K. Ramakrishnan                             Email:[email-masked]
AT&T Labs-Research, Rm. A155                   Tel: (973)360-8766
180 Park Ave, Florham Park, N.J. 07932         Fax: (973) 360-8050
	URL: http://www.research.att.com/info/kkrama

---

From: Grenville Armitage <[email-masked]>
Date: Sat, 03 Jun 2000 12:01:53 -0700

this is one of the problems i have with the current atomic
functional unit called "algorithmic dropper". clearly
the algorithm and the subsequent action are seperable,
and doing so makes it easier to shoehorn in ECN-related
functions at a later date.

i'd like the idea of an 'algorithmic selector' function block
that has three possible outputs (a) Pass packet, (b) Pass and
mark packet, and (c) Drop packet. Diagramatically output (b) would
feed a Marker stage, while output (c) would feed a Dropper (aka
'Absolute Dropper') stage. The 'algorithmic dropper' would go
away as an atomic unit of plumbing, being functionally
replaced by 'algorithmic selector' -> 'dropper' in the diffserv
model. when ECN moves along the path of standardization, we
add a 'marker' block to an additional output of the 'algorithmic
selector' block in the plumbing diagrams, and voila!

no?

cheers,
gja

-- 
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley

---

From: Fred Baker <[email-masked]>
Date: Sat, 03 Jun 2000 11:56:14 -0700

>function, instead of "dropper"?

the classifier, with the meter, *is* a selection function - that's all it 
does - and the action that results is what is done to "treat the packet in 
some distinctive manner". I'll agree that something that ECN Marks is not 
actually "dropping" the packet, so the term "dropper" may be unfortunate, 
but there are enough squirrely architectural things going on here without 
confusing the language.

---

From: jamal <[email-masked]>
Date: Sun, 4 Jun 2000 12:57:08 -0400 (EDT)

> you care to offer alternative language that would make this more clear?

The closest i can come up with is "prequeue algorithm". Dropping happens
to be one scheme. Algorithmic dropping is a subset. 
But then "prequeue algorithm" doesnt sound very cool the way "Algorithmic
dropper" comes out ;->

cheers,
jamal

---

From: Grenville Armitage <[email-masked]>
Date: Sun, 04 Jun 2000 15:28:09 -0700

Fred Baker wrote:
	[..]
> I'll agree that something that ECN Marks is not

Fred,

I'm not even convinced we need an 'Algorithmic Dropper' functional
block. Sure, we need to be able to talk about algorithmic dropping,
but that doesn't require its own functional block. Even in the
current Fig.5s (present and proposed) this functional block is
clearly being made from other blocks. So how about we strip away
the boundary, and generalize what was inside. I'm not good at
ASCII art, but here's my rendition of Fig 5 in text:

 - Packet arrives
 - Algorithmic Action Selector (AAS) picks action
	Inputs to AAS:
		(i) Packet
		(ii) Queue state (averaged/smoothed)
		(iii) Other?
	Possible actions:
		(a) enqueue packet (line points into queue)
		(b) drop packet (line points to bit bucket, aka Drop)
		(c) mark and enqueue packet (line points into
		    queue via Mark box)

With such a block it is still easy to talk of algorithmic marking
or algorithmic dropping as actual behaviors instantiated through
appropriate wiring of such an AAS and queue stage.

cheers,
gja

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 05 Jun 2000 11:11:57 -0500

> on congestion based pricing " ECN instead of Diffserv" ;->]

Yes, I was wondering whether I needed to take some over-ripe
fruit for that session ;-)

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 05 Jun 2000 11:33:57 -0500

What's troubling me in this whole discussion is that we aren't defining
an implementation blueprint for a diffserv+ECN router. I don't really
see why we need to create a hook for ECN in the diffserv conceptual model. 
Unless there is something I'm missing, it is a completely separable function
conceptually.

   Brian

---

From: Grenville Armitage <[email-masked]>
Date: Mon, 05 Jun 2000 11:32:47 -0700

Brian,

You're right they're seperable conceptually.

The point is when presented with a diffserv conceptual model that
easily extends to cover ECN, or requires contortions to cover ECN,
some of us would prefer the former. Especially since it should
make no difference to the validity of the diffserv-only version
of the model.

Think of it another way - today we have PHBs that convey 'marking'
indicating that a packet vioated a traffic profile. Okay, so
that's unrelated to queue level. But perhaps someone, someday wants
to define a diffserv PHB Group where the DSCP is modified (marked)
based on congestion indications coming from the queue. In that
case it'd be nice if the diffserv conceptual model apriori covered
the case where local congestion state (aka queue state) could cause
either 'mark' actions and 'drop' actions. Just in case.

cheers,
gja