Re: Doc[1] Charting Networks

Glenn Mansfield <glenn@aic.co.jp> Tue, 10 November 1992 14:19 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02117; 10 Nov 92 9:19 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id az01969; 10 Nov 92 9:19 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id ab03358; 10 Nov 92 7:53 EST
Received: from haig.cs.ucl.ac.uk by IETF.CNRI.Reston.VA.US id aa29830; 10 Nov 92 3:16 EST
Received: from 150.80.254.1 by haig.cs.ucl.ac.uk with Internet SMTP id <g.01897-0@haig.cs.ucl.ac.uk>; Tue, 10 Nov 1992 06:54:44 +0000
Received: by aic-wide.aic.co.jp (4.1/2.7W) id AA00175; Tue, 10 Nov 92 15:52:46 JST
Date: Tue, 10 Nov 92 15:52:46 JST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Glenn Mansfield <glenn@aic.co.jp>
Return-Path: <glenn@aic.co.jp>
Message-Id: <9211100652.AA00175@aic-wide.aic.co.jp>
To: VALDIS@vtvm1.cc.vt.edu
Subject: Re: Doc[1] Charting Networks
Cc: glenn@aic.co.jp, ic-tech@isode.com, osi-ds@cs.ucl.ac.uk, spp@aic.co.jp, thomas@aic.co.jp

Valdis

In essence your question is how we intend to represent the complexities of
charge, cost, traffic in the attributes of the objects. 

Good questions. I guess that the same question applies to the routing-policy 
attribute in the ipNetworkImageObject, too.

We have thought about it and concluded two things 
	1. The taxonomy of the charge/cost/traffic/routing policies should
	   be dealt with in detail and in a separate place (preferably by 
	   som other person ;-). Some work on Routing policy requirements 
	   are done. We are not aware of similar works in charge, cost, 
	   traffic. 
	  [The SoftPages  project itself ofcourse works on a very simple 
	   model of charge,cost & traffic- but we do not claim it to be
	   a general model. ( Waiting for someone to do some work in this 
	   direction ;-) ]
	2. In the proposed Directory model it is possible to take care of 
	   fairly complex semantics using 
		- appropriate syntax for attributes something like the tuple
		  they use for describing "policy terms" for routing
		- multiple values of the same attributes

I hope this answers your question.

cheers

glenn

 *****************************************************************
 * Glenn Mansfield                                               *
 * AIC Systems Laboratory                Phone : +81-22-279-3310 *
 * 6-6-3, Minami Yoshinari               Fax   : +81-22-279-3640 *
 * Sendai, Japan. 989-32                 e-mail: glenn@aic.co.jp *
 *****************************************************************

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
   >>From ic-tech-request@isode.com Tue Nov 10 09:55:15 1992
   >>Received: from cosmos.aic.co.jp by melody.aic.co.jp (4.1/6.4J.6-91/1/29)
   >>	id AA15035; Tue, 10 Nov 92 09:55:14 JST
   >>Received: from aic-wide.aic.co.jp (bass) by cosmos.aic.co.jp (4.0/6.4J.6-92/2)
   >>	id AA00804; Tue, 10 Nov 92 09:55:11 JST
   >>Received: from haig.cs.ucl.ac.uk by aic-wide.aic.co.jp (4.1/2.7W)
   >>	id AA22773; Tue, 10 Nov 92 06:00:07 JST
   >>Return-Path: <ic-tech-request@isode.com>
   >>Received: from glengoyne.isode.com by haig.cs.ucl.ac.uk with Internet SMTP 
   >>          id <g.07593-0@haig.cs.ucl.ac.uk>uk>; Mon, 9 Nov 1992 20:26:26 +0000
   >>Received: from haig.cs.ucl.ac.uk by glengoyne.isode.com with SMTP (PP) 
   >>          id <02874-64@glengoyne.isode.com>om>; Mon, 9 Nov 1992 20:24:26 +0000
   >>Received: from vtvm1.cc.vt.edu by haig.cs.ucl.ac.uk with Internet SMTP 
   >>          id <g.07368-0@haig.cs.ucl.ac.uk>uk>; Mon, 9 Nov 1992 20:06:37 +0000
   >>Received: from vtvm1.cc.vt.edu by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with BSMTP 
   >>          id 6282; Mon, 09 Nov 92 15:05:17 EST
   >>Received: from vtvm1.cc.vt.edu (VALDIS) 
   >>          by vtvm1.cc.vt.edu (Mailer R2.08 R208002) with BSMTP id 2663;
   >>          Mon, 09 Nov 92 15:05:17 EST
   >>Date: Mon, 09 Nov 92 14:51:29 EST
   >>From: Valdis Kletnieks <VALDIS@vtvm1.cc.vt.edu>
   >>Organization: Virginia Polytechnic Institute
   >>Subject: Re: Doc[1] Charting Networks
   >>To: Glenn Mansfield <glenn@aic.co.jp>jp>, spp@aic.co.jp
   >>Cc: ic-tech@isode.com, osi-ds@cs.ucl.ac.uk, thomas@aic.co.jp
   >>In-Reply-To: <9211090220.AA07142@aic-wide.aic.co.jp>
   >>Message-Id: <921109.145129.EST.VALDIS@vtvm1.cc.vt.edu>
   >>Status: R
   >>
   >>On Mon, 9 Nov 92 11:20:08 JST you said:
   >>> 5.2.3 Line
   >> ...
   >>> line OBJECT CLASS
   >> ...
   >>>   charge         :: numericStringSyntax,
   >>>        /* to be paid by user for transmission
   >>>             of data (per packet/byte/time...)  */
   >>
   >>It's  crucial that  the units  be  carried along  here. There  is a  big
   >>difference  between $2000/month  and $2000/packet.  Of course,  here you
   >>can make a guess that $2000US is a  "per month" charge - but what if the
   >>value is $2.50 - is this a "weekly" or a "per megabyte" charge?
   >>
   >>Also, a numeric value alone isnt much  use. If the object described is a
   >>T-1 link running  from an ENSS in Ithaca, NY  to Montpelier, France, are
   >>the  units  US dollars  or  francs?  And  what effect  do  international
   >>currency fluctuations have?
   >>
   >>>   cost      :: numericStringSyntax,
   >>>        /* to be paid to service provider for use of line
   >>>             (per month, traffic...)  */
   >>Same as above..
   >>
   >>>   traffic        :: numericStringSyntax
   >>>        /* (average) use in percent of nominal bandwidth */
   >>>         }
   >>
   >>What timeframe  is this "average" taken  over? And how do  you deal with
   >>objects  with widely  varying loads  over time/space?  For instance,  we
   >>have  a  large (about  800  node)  Ethernet-based network  that  employs
   >>bridges  for traffic  filtering. Some  segments (for  instance, over  in
   >>McBryde Hall,  where both Math and  CS are located) run  quite congested
   >>during  the day,  but  are essentially  idle at  night,  except for  the
   >>occasional NTP packet.  Other segments sit at a pretty  constant 15% the
   >>entire day.
   >>
   >>Also, remember that  for many media types, nominal  bandwidth has little
   >>relationship to actual  capacity. Note that both  the Ethernet collision
   >>detection/avoidance and  most routers perform somewhat  differently when
   >>presented with a few 8K NFS  packets fragmented into 1500 byte segments,
   >>an  several  zillion  telnet  packets  with  one  character  of  data  a
   >>packet....
   >>
   >>
   >>                                  Valdis Kletnieks
   >>                                  Computer Systems Engineer
   >>                                  Virginia Polytechnic Institute
   >>