Subject: [Diffserv] draft-ietf-diffserv-model-02.txt

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Mar 2000 09:43:55 -0600

draft-ietf-diffserv-model-02.txt has been submitted and will be announced as soon
as it gets through the queue at ietf.org. 

Sorry it is so late but the illness of one of the authors took priority. 
As co-chair, I did the final edits myself and there wasn't time to consult 
with the authors. However, I think this version is consistemt with the
WG discussions in Washington and on the list.

We are very late with this. The WG last call for this and 
the MIB will come as soon as possible.

fyi here is the disposition of various comments collated by Steve Blake:

> 1.    10/25/99 
>     From: Nick Williamson <[email-masked]>
> 
>       Add text to model draft to discuss classification with IP fragmentation.

Added a brief note saying that MF classification doesn't work on fragments
> 
> 
> 2.  MIB comment   10/26/99  
>     From: Alain BURGAIN <[email-masked]>
> 
>       Allow multi-level traffic control (multi-stage classification and TC).
>       See Brian Carpenter's response  (IETF/diff-serv/2410).

Added a short section referring to cascaded TCBs
> 
> 
> 3.    11/5/99
>     From: Kathleen Nichols <[email-masked]>
> 
>     - Come up with a better term for "mirror" (replicator?)

done
> 
>     - Monitor only increments counter.  Do you need an element
>       to count down (e.g., a queue length monitor?)

changed "increment" to "update"
> 
>     - TCB definition needs work.  Call it a "logical datapath
>       entity" instead of element.  Also, don't call it a "black box".

rephrased
> 
>     - Refer to RSVP-optional box as a "QoS agent", and refer to
>       RSVP as one alternative.  Text is otherwise fine.

done
> 
>     - Have a (not strong) objection to including MPLS discussion;
>       let the MPLS WG handle this.

removed most of it; not our job

> 
>     - Reference class selector PHBs when discussing queues and queue
>       sets in Sec. 7. 
done
> 
> 
> 4.  IETF/diff-serv/2532   11/5/99
>     From: Alain BURGAIN <[email-masked]>
> 
>     - Parameterize queue thresholds in terms of queueing delay, not
>       # of packets.

there is no evidence of consensus for this; not done
> 
> 
> 5.     11/5/99
>     From: Constantinos <[email-masked]>
> 
>     - Need to include Class Selectors

done
> 
>     - Class Selectors could have more general parameters

well, there is priority in there
> 
>     - Queue parameters are not really implementation and services-
>       independent.

strictly true, but we have described a set of parameters that should
cover all the PHBs defined so far. That's all you can reasonably expect.
> 
> 
> 6.     11/7/99
>     From: Brian E Carpenter <[email-masked]>
> 
>     "I'd be perfectly happy if the draft said that the class selectors
>     don't [necessarily] need any parameters; my point is that people
>     tend to spend all their ink on AF and EF, and that is not right."

see above
> 
> 
> 7.    11/9/99
>     From: Yoram Bernet <[email-masked]>
> 
>     Long note 
This was the summary of the discussion at the last IETF; all the
points seem to be covered in the new draft
> 
> 
> 8.     12/7/99
>     From: Roch Guerin  <[email-masked]>
> 
>     Model shouldn't preclude drop-from-the-middle buffer management, etc.
>     "So I would say that a discarding element is an element which for every
>     state change in the buffer, i.e., a packet leaving or arriving, is
>     making decisions on which packets to keep/accept in the buffer based on
>     a discarding discipline.  This is not much different from what you have,
>     but I thought it might be important to clarify things."

the current discarder text covers this
> 
> 
> 9.     12/8/99
>     From: Longsong Lin <[email-masked]>
> 
>     Shaper shouldn't necessarily be embedded in output scheduling.
see below #11
> 
> 
> 10.    1/20/00
>     From: Thomas Eklund  <[email-masked]>
> 
>     I have some questions about the draft-ietf-diffserv-model-01.txt...
> 
>     I wonder why TCB (Traffic Conditioning Block) is specified to include the
>     classifier stage??
> 
>     I would like to see something like
>     Filter Block (BA, MF filtering)
>     Traffic Conditioning Block (Metering, Marking, Shaping, Dropping,
>     Queuing/Scheduling)
> 
>     So that you set the ingress and egress filtering rules in the FB and applies
>     a TCB for every FB.
> 
>     So the FB is in, out, in/out (flow).
> 
>     Then I would also like to see a paper on how ipsec in tunnel mode over
>     diffserv should be handled at the same time in FB. Or is there any work
>     already done on this?
> 
>     So the model would become:
>     FB + TCB = (filtering block for both security filters and qos
>     classification) + (and a traffic conditioning block that apply the traffic
>     behaviour) = What treatment and how a packet is forwarded 
> 
>       1/21/00
> 
>     Oops I forgot the forwarder block FOB... But that was obviuos but I did not
>     see that in the draft.
> 
>     Then you would have three buliding blocks; Forwarding block, filter block
>     and traffic conditioning block...
> 
>     This would be very good to fit the different models i HW (shared memory
>     design, crossbar, shared bus etc...)...   
> 
>     I dont know if this should be included in the draft or a new one..?
>     Any Comments?

see below #11
> 
> 
> 11.    1/21/00
>     From: Brian Carpenter <[email-masked]>
> 
>     We aren't designing hardware; this is only a conceptual model.
> 
>     The current functional decomposition has been debated for quite
>     a while. Any choice of decomposition is arbitrary, and this is
>     the one that got consensus.
> 
>     As soon as we get the draft revised according to the discussion
>     in Washington, we will be going for Informational RFC.
> 

   Brian Carpenter
   diffserv co-chair

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