Subject: Re: [ippm] A One-way Active Measurement Protocol Requirements draft

From: Victor Reijs <[email-masked]>
Date: Fri, 07 Sep 2001 16:48:11 +0100

Hello Stas,

Hope you had time to look at my below remarks. I have another remarks; I
know it could be too much weight on the MP, but incorporating Jini in
this, is that an option?
See for more info: http://www.sun.com/jini/whitepapers/

All the best,

Victor

Victor Reijs wrote:
> 
> Hello Stas,
> 
> I am back in business...
> 
> stanislav shalunov wrote:
> 
> > > section 2
> > > "With growing availability of good time sources to network nodes, it
> > >    becomes increasingly possible to measure one-way IP performance
> > >    metrics with high precision."
> > > Why is it a one-way protocol?
> 
> I agree fully with Henks remarks here. I think we need to make an open
> protocol and this should include e.g. the future pings or other two way
> measurements. I don't understand why the measurment protocol will change
> much, because of this demand.
> 
> > And why not active and passive?
> >
> > I think passive measurements are way outside of scope of the activity
> > here.  (Not to imply that they're less valuable.)  I see little scope
> > for interoperable remote passive measurements.  I wouldn't be the one
> > to write security considerations section for that.  "Could you show me
> > the first data packet of each POP session on your network?" :-)
> 
> Passive measruement are most of the time easier to ask for than active
> measurements with some network managers!
> Active measurements load the network, CPU, disks, while passive
> (possible;-) don't. So the security issues with active measurements
> (like resource control) are much more important than for passive
> measurements.
> For passive measurement, I can understand that network managers don't
> want to disclose some information, but for that we also have security
> control inplace (can be precisely the same one as for resource security
> mentioned in 6, I would say).
> 
> So I see no intrinsic differances between active and passive measurement
> looking at the measurement protocol and the security side.
> 
> >
> > > I don't think this is the driving force behind MP. For one possible
> > > measurement (OWD) this could indeed be handy, but I would think that
> > > this is an attribute of the protocol (MP-Control?) to find out if 'time'
> > > can be measured in absolute terms on the systems in measurement.
> >
> > (Relatively) accurate timestamps are required for more than delay
> > measurements.  For example, loss metrics are defined in a way that
> > requires specifying the time when each loss event occurs.
> 
> Understand, so it is not mandaroty for doing measurements. Still an
> attribute for the protocol, I would say.
> 
> >
> > > But what about the loss pattern?
> >
> > Since you get the raw measurement data, you can analyze the loss
> > patterns to a certain extent...
> >
> > > In general, I think non-singletons should be allowed in this protocol.
> >
> > Sure.  But should they be made a requirement?
> 
> What is a singleton? Is e.g. 'raw measurment data' a non-singleton? And
> the result for a OWD measurement a singleton (one figure). Again,
> perhaps I don't understand the word singleton.
> 
> >
> > > " and application traffic
> > >    simulation aren't areas that the protocol(s) need to address."
> > > I my view the MP should also be able to do this (perhaps we don't
> > > concentrate on this, but never the less).
> >
> > That's a big can of worms.  Placing it in the requirements document
> > seems to be a good way to never arrive even at a more modest protocol
> > that'll measure standard metrics.
> 
> I see even e.g. testing OWD or packet loss as an application! So I don't
> think the can of worms is that big (you already have it;-).
> The main advantage of seeing it as an 'application', is that you have to
> build in the protocol a method of downloading the
> application/measurement. But I think you always need to do this; I don't
> think that a protocol that does not have this download function in it,
> will survive a fast increasing number of tests and their upgrades. So
> upgrading could help keep this measurement infrastructure manageable.
> I know there are some worms, but lets tackle them!
> 
> >
> > > Section 4.3
> > > "These protocols are further referred to as OWDP-Test and
> > >    OWDP-Control, respectively."
> > > I think we need another protocol for downloading code to the endpoints:
> > > MP-Code (and also be part of MP-Control).
> >
> > What do you mean by "code"?  As in, "source code" or "executable
> > code"?  Or do you mean something else?
> 
> Good point! That is part of this can of worms (isn't it). Say a code
> that can be understood by any endpoint (irregardless which operating
> system), something like Java?
> Java is not that lightweight, I understand, so perhaps we need to make
> it optional...
> Perhaps scripting if possible (like done by Chariot of NetIQ, is not
> fully what I want though...).
> 
> (although I don't like the optional part, because then it will not be
> implemented and will result in a measurement infrastructure which will
> not be managable).
> 
> >
> > > Section 4.4
> > > "Since the protocol needs to be able to measure individual packet
> > >       delivery time and has to run on various machines, it needs to
> > >       support UDP as transport protocol."
> > > What is the relation between 'various machines' and 'UDP'? Are this not
> > > two separate characteristics?
> >
> > UDP is the only things that'll let you easily do measurements with
> > arbitrary machines.
> 
> And if you want to do e.g. BTC measurements? I have no problem that the
> MP-Control protocol also has this as an attribute (so that you can find
> out which protocols are supported).
> 
> >
> > > "schedule zero or more OWDP-Test sessions (which do not have to be
> > >       between the peers of OWDP-Control conversation);"
> > > Part of this (or perhaps part of MP-Test) is that resource control of
> > > the measurement system is evaluated/monitored/reported a) before the
> > > test is done (perhaps re-schedule test) and b) during the test.
> >
> > I don't understand.
> 
> Active measurements will load your resource (disk, CPU, link, etc.), so
> you will have to be able to manage this (certainly as the network
> manager that has granted access to others to do these tests). So you
> need to do resource control before doing the test (estimates) and when
> actually doing the test (and you have to report back on the load of
> these resource towards the test initiator).
> Passive measurements don't have this problem at this level, but still
> yuu want to control there e.g. the disk load).
> 
> Hope this makes it more clearer.
> 
> All the best,
> 
> Victor

---

From: Victor Reijs <[email-masked]>
Date: Fri, 28 Sep 2001 11:57:44 +0100

Hello all of you,

I have seenno reactions on my mail. I can't understand it is all
accepted;-)

All the best,

Victor

> > Hope this makes it more clearer.
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm