Subject: Guaranteed Service C, D error terms

From: Paul WHITE <[email-masked]>
Date: Thu, 15 Jul 1999 18:04:49 +0100

Hello folks,

I'm currently doing some simulations of intserv reservation protocols running 
over heterogeneous networks. I therefore need some typical values of 
guaranteed service C, D error terms for different link layers, e.g.. ATM, 
SONET, switched ethernet etc. If anyone has any such values or can point me in 
the right direction then I'd be very grateful.

cheers

Paul

-------------------------------------------------------------------------------
Paul White
Department of Computer Science, University College London, Tel: (0171) 419 3701
Gower Street, WC1E 6BT, London, England                    Fax: (0171) 387 1397
           
Mobile: 0956 675801
-------------------------------------------------------------------------------

---

From: Roch Guerin <[email-masked]>
Date: Fri, 16 Jul 1999 11:25:31 -0400

Paul,

C is a "rate" dependent error term, so the underlying link layer does
not really come into play.  A typical value (from WFQ) is one maximum
size packet (for the flow in question).  The delay contribution would
then be the time it takes to transmit that packet at the reserved rate.

D does depend to some extent of the link layer.  On a "straight"
pt-to-pt link it is typically the time to send a max size (the link MTU)
packet over the link.  You may need to add some extra terms depending on
the specifics of the systems, i.e., the latency of the node to transfer
packets from input to output).  On something like E/N, if it's not used
in a pt-to-pt mode, then you need to factor in the potential impact of
contention resolution (not easy).  Similarly, for ATM you may need to
look at how packet level guarantees are implemented at the cell level,
i.e., any potential for interleaving.  Again, this is something that
depends on other factors than just the "link".  My suggestion would be
to take a representative system and derive the appropriate values for
that system and then use them in your study.

Roch

---

From: Paul WHITE <[email-masked]>
Date: Mon, 19 Jul 1999 21:04:42 +0100

> This is a multi-part message in MIME format.
> --------------982C2F9234644E6E45280233
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> Paul,
> 

Roch,

thanks for your response and all the other pointers I've received. 

As far as IP over SONET is concerned the following values appear reasonable to 
me - please correct me if I'm wrong

IP over SONET
-------------
- maximum PPP datagram size is 1500 bytes(RFC1661) 
- assuming guranteed service is implemented using WFQ and that link is 
STS-3(155M) then we have

D = 1500*8/155M = 77uS

C = 1500 bytes

As far as IP over ATM is concerned, I guess your response above kind of begs 
the question "what is a representative system for ATM?"

IP over ATM
- ------------
RFC2381 suggests that for an ATM network it will be usual to advertise a C 
value equal to 0 and to allow for all delay in the D term. The question then 
is what values for the D term can we expect? Well I've seen some ATM SLAs from 
Sprint that advertise one-way end to end delays less than 36ms so this must 
represent an upper bound on potential values of D terms for an IP over ATM 
hop. But I'm not sure what we could expect a typical value of D term to be in 
practice for an IP over ATM hop. Any ideas?

thanks

Paul

------------------------------------------------------------

>From RFC2381: Interoperation of CLS and GS with ATM

   "The values of C and D that a router advertises depend on both the
   router packet scheduler and the characteristics of the subnet
   attached to the router.  Each router (or the source host) takes
   responsibility for its downstream subnet in its advertisement.  For
   example, if the subnet is a simple point-to-point link, the subnet-
   specific parts of C and D need to account for the link transmission
   rate and MTU.  An ATM subnet is generally more complex.

   For this discussion, we consider only the ATM subnet-specific
   components, denoted C_ATM and D_ATM.  The ATM network can be
   represented as a "pure delay" element, where the variable queueing
   delay, given by CVD is captured in D_ATM, and C_ATM is set to zero.
   It is possible to use C_ATM only when the ATM service rate equals R.
   This may be the case, for example with a CBR VC with PCR = R.

   Usually it will be simpler to just advertise the total delay
   variation (CDV) in D_ATM.

   As discussed in Section 2.6, the edge router keeps a table with
   values of MPL and D_ATM for each egress router it needs to share VCs
   with.  The value of D_ATM contributes to the D parameter advertised
   by the edge router, and SHOULD accurately reflect the CDV that the
   router will get in a VC when it is set up.  Factors that affect CDV,
   such as statistical multiplexing in the ATM network, SHOULD be taken
   into account when compiling data for the router's table.  In case of
   uncertainty, D_ATM can be set to an upper bound.  When an RESV
   message arrives, causing a VC to be set up, the requested values for
   CTD and CDV can be relaxed using the slack term in the receiver
   RSpec:"