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 >>
- Doc[1] Charting Networks Glenn Mansfield
- Re: Doc[1] Charting Networks Peter.Sylvester
- Re: Doc[1] Charting Networks Valdis Kletnieks
- Re: Doc[1] Charting Networks Glenn Mansfield
- Re: Doc[1] Charting Networks Glenn Mansfield
- Re: Doc[1] Charting Networks Tim Howes