Subject: [Diffserv] TCB Consistency on Cascaded Diffserv-compliant Network Devices

From: Lei Yao <[email-masked]>
Date: Mon, 20 Aug 2001 17:59:06 -0400

All,

According to the discussion in the last IETF meeting, we propose the
following descriptions for TCB consistency as another appendix of Diffserv
informal model.

Your comments are welcome.

Appendix B: TCB Consistency Requirements on Cascaded Diffserv-compliant
Network Devices

The Diffserv informal model identifies the Diffserv functional modules to be
implemented on a Diffserv-compliant network device. These functional modules
can be combined into Traffic Conditioning Blocks (TCBs). Multiple
Diffserv-compliant network devices may be cascaded in end-to-end forwarding
paths of data traffic. For example, as shown in Figure 1, in a typical
Internet scenario with unidirectional data flow, an edge router at a source
customer site sends packets to a border router of the source ISP. The source
ISP then forwards the packets across its network to a border router of the
destination ISP. Finally, the destination ISP passes the packets to an edge
router at the destination customer site. The Diffserv architecture requires
the use of TCBs at the edge of a Diffserv network or between inter-domain
Diffserv networks for service enforcement purpose.

    Source	        Source	          Destination	   Destination
   Customer	          ISP		         ISP		    Customer
     +--------+     +-----------+     +-----------+     +--------+
     |  Edge  |     |   Border  |     |  Border   |     |  Edge  |
     | Router |     |   Router  |     |  Router   |     | Router |
     |        |     |	        |     |	       |     |        |
     |   +----|data +----+ +----+data +----+ +----+data +----+   |
     |   |TCB1|---->|TCB2| |TCB3|---->|TCB4| |TCB5|---->|TCB6|   |
     |   +----|     +----+ +----+     +----+ +----+     +----+   |
     |	    |     |           |     |	       |     |	       |
     |	    |     |           |     |	       |     |	       |
     +--------+     +-----------+     +-----------+     +--------+

       Figure 1. Cascaded Diffserv-compliant Network Devices

Diffserv-compliant routers deployed by different customers or ISPs may use
different vendor implementations. These vendors may choose different
algorithms to implement the same Diffserv functional module in TCBs. As a
result, packets conforming to an upstream TCB may become non-conforming to
its downstream TCB and customers may observe unexpected impacts to
end-to-end performance. For example, assuming a traffic flow can achieve the
same 99% delivery probability for conforming traffic at each TCB of Figure 1
and non-conforming packets are dropped, in the worst case only about 94% of
the traffic from the source customer will eventually reach the destination
customer.

Therefore, a general requirement from ISPs and customers is to achieve
service consistency between cascaded TCBs of different implementations, e.g.
TCB1-TCB2 (Customer-ISP), TCB3-TCB4 (ISP-ISP) and TCB5-TCB6 (ISP-customer)
in Figure 1. A natural definition for service consistency is that different
implementations of TCBs conforming to the same Service Level Specification
(SLS) must have the same external observable behavior on packet processing.
The above definition can be further quantified in the following ways:
- In a strict definition, conforming/nonconforming packets from an upstream
TCB must result in the same conforming/nonconforming behavior in the
downstream TCB.
- In a loose definition, a traffic profile should result in the same
fraction of non-conforming packets in both upstream and downstream TCBs and
only a small percentage (e.g. <0.1%) of conforming packets of an upstream
TCB cam be non-conforming to the downstream TCB.

Below are several scenarios in which some guidelines should be developed and
followed in order to realize service consistency between cascaded TCBs that
use different implementations of the same Diffserv functional module.

Scenario 1: Metering Consistency
Meters are typically used to check the conformance of the received traffic
to a pre-configured traffic profile. It is generally required by ISPs that
two consecutive meters provisioned according to the same traffic profile
perform conformance checking consistently. For example, if the customer
traffic has been shaped according to a traffic profile, the shaped traffic
must appear conforming to a subsequent policer using the same traffic
profile.

Five meter algorithms are described in the body of the informal model:
- Average Rate
- Exponential Weighted Moving Average
- Simple Token Bucket (both loose and strict)
- Multi-stage Token Bucket
- Null
Note that, if meter algorithm differs, conformance check may differ. Even if
meter algorithm and major parameters are the same, conformance check may
still differ. For example, two simple token bucket meters with the same
token rate and bucket depth but different token bucket update intervals may
result in different conforming/non-conforming decisions on packet-by-packet
basis or different fraction of nonconforming packets on a traffic flow.

The update interval together with token rate determines how often and how
many tokens can be added into the token bucket with the bucket depth as the
upper limit of number of tokens in the bucket. For example, for a token
bucket of (r,b) and a update interval of t, the number of tokens are added
into the bucket at every t sec is given by r*t. To achieve consistent
conformance check with simple token bucket meters, the following
implementation guidelines should be followed:
- The bucket depth must be at least the maximum packet size.
- The buffer size of a shaper must be bigger than r*t+b .
- The update interval should ensure r*t is less than or equal to the
smallest packet size. Note that, instead of periodical token update,
event-drive token update (i.e. per-packet arrival event) can always meet the
above requirement for update interval.

Other guidelines for cases where the metering algorithms differ should also
be developed. For example, a loose token bucket following a strict token
bucket should yield consistent behavior.

Scenario 2: Scheduling Consistency
The Diffserv architecture requires the use of separate queues to serve
different traffic aggregates (i.e. classes). Multiple scheduling algorithms,
such as strict priority, WRR, WFQ and CBQ, can be use to select the packet
to be forwarded among multiple outputs of the queues. A Diffserv-compliant
router may support multiple scheduling algorithms. ISPs can select the most
appropriate one to achieve specific QoS objectives as described in a
Diffserv PDB.

Schedulers with different scheduling algorithms or different implementations
of the same scheduling algorithm usually can guarantee consistent
throughput. However, they may not result in consistent queuing delay
variation. For example, two WRR schedulers may use different round-robin
cycle times. One may send a packet from each queue per cycle while the other
may send a block of packets from each queue per cycle.

Scenario 3: Marking Consistency
Although Diffserv architecture requires only locally significant DSCP
marking (e.g. within a single ISP domain), the nature of Internet (the
network of networks) may require different processing of marked packets in a
coordinated manner in order to achieve consistent end-to-end Diffserv
service in some circumstances. Below are several examples in which the
coordinated marking between cascaded ISPs is required:

Example 1: As shown in Figure 1, for AF PHB and PDB that allow the remarking
of burst traffic above a committed rate with higher drop precedence, if the
source ISP uses multiple drop precedence while the destination ISP does not
use drop precedence, the destination ISP should honor the drop precedence
marked by the source ISP and discard only those packets with higher values
of drop precedence.

Example 2: If the source ISP supports standard DSCP marking while the
destination ISP supports proprietary marking (e.g. legacy TOS marking), the
ingress TCB of the destination ISP (TCB4) should be able to perform the
mapping between standard DSCP marking and its proprietary marking in the
direction as shown in Figure 1, and vice versa in the reversed direction.

Example 3: If the source ISP supports one subset of AF drop precedence while
the destination ISP supports another subset of AF drop precedence, the
ingress TCB of the destination ISP (TCB4) should be able to perform the
mapping between the two different subsets of AF drop precedence.

_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: "Andrew Smith" <[email-masked]>
Date: Mon, 20 Aug 2001 16:43:54 -0700

I don't believe that this material, whilst very useful, should be placed
into the Model draft.

1. It has very little to do with the management model described in the
draft.
2. It is very specific to one view of deploying Diffserv but is not
generally applicable.
3. It uses the "S" word ("services") a lot in a document that, very
specifically, deals only with single nodes.

I'd suggest it be published as an informational RFC (or try to persuade the
Diffserv WG chairs to take it up as a WG work item - is there a need for a
Diffserv Deployment WG?).

Just my 2c, as one of the draft authors - apologies if I am missing some
context from not having been in London to hear the discussion (any minutes
available yet in any form?).

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Lei Yao
Sent: Monday, August 20, 2001 2:59 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [Diffserv] TCB Consistency on Cascaded Diffserv-compliant
Network Devices

All,

...

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Aug 2001 15:34:30 -0500

I haven't seen any support, or the opposite, for adding this material. 
Now is the time.

Personal opinion: I think this is out of place and should not be added.
It doesn't seem to me to address the issue raised in London, according
to the minutes. It is commentary on the overall architecture, and does not 
add anything to the router model as such. I happen to agree with the words, 
but IMHO they just don't belong in the router model. In fact, they are
effectively commentary on these sentences in RFC 2475: 
  "G.9:  Each PHB specification should include a section specifying
   minimal conformance requirements for implementations of the PHB
   group.  This conformance section is intended to provide a means for
   specifying the details of a behavior while allowing for
   implementation variation to the extent permitted by the PHB
   specification."

     Brian

---

From: Dave McDysan <[email-masked]>
Date: Wed, 29 Aug 2001 17:14:40 -0400

Actually, on August 20, Andrew Smith (the editor) did not believe that this
text was appropriate for the router model either.

From the minutes published by Kathie:

"It was agreed that some warnings about this should be in the
informal model, although specifics belong in specific PDBs where they
apply."

After reviewing the informal model, we could not come up with a placement
that made sense for text in any particular section, which is why we proposed
a separate appendix. This is an indication that the concept is not a good
fit with the scope of the body of the document, and hence not including it
in the informal model.

Possibly we need to state our point better, but we believe that the
applicability is at the edges of PDBs, and not on a per PHB basis. Our
commentary on the nodal informal model was based upon trying to assemble
PHBs into useful PDBs. As such, considerations like these might better be
placed in a PDB document.

If the WG is interested in continuing to discuss and document these types of
practical considerations involved in the implementation of Diffserv, we
would be happy to volunteer to editorially capture any consensus that is
reached in whatever document(s) that are appropriate.

Dave

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Wednesday, August 29, 2001 4:35 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Diffserv] TCB Consistency on Cascaded Diffserv-compliant
> NetworkDevices
>
>
> >    Customer               ISP                    ISP
>     Customer

---

From: Kathleen Nichols <[email-masked]>
Date: Wed, 29 Aug 2001 15:11:52 -0700

...what we *have* had lots of discussion about in various
diffserv WG meetings and on the mailing list is that the
"downstream" domain is expected to be very clear about how
it is policing and what it is policing to. The "upstream"
domain is then able to conform to that or not as desired.
So I think that principle has always been part of the 
diffserv architecture. What I believe Dave is concerned about
is the specifics of implmenting that principle. 

What we've discussed with PDBs is that they should include
the specifics of the particular traffic aggregate is being
policed. This seems like the kind of data that would need
to be made public to any ISP or customer. If we're not
capturing that in our definition of PDBs, then it needs to
be reworked.

	Kathie

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 29 Aug 2001 18:28:12 -0400

I would agree that this is not the right text.  Among other things, the 
problem causing the concern is a mismatch between a scheduler and the 
succeeding meter (in different devices, probably across a diffserv 
boundary) and none of the examples even talk about that case.
I think we are better off not trying to describe implementation issues of 
this complexity at this time.
Yours,
Joel M. Halpern

At 03:34 PM 8/29/01 -0500, Brian E Carpenter wrote:
>Archive: 
>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Aug 2001 16:22:08 -0500

I'll take it upon myself to suggest that the authors consider turning this
into an I-D, to see if it stands up as a separate document. As Joel says,
in the absence of several years of experience, we may be getting ahead
of ourselves. (That is the same concern that Kathie and I have about
publishing PDB definitions without deployment experience.)

   Brian