RE: time tracing utility

[neil.2.harrison@bt.com]

Tom,  You asked for some service provider views on this, viz:
> It would be interesting to hear from service providers on this topic.

So here are the issues to consider before getting into any protocol/solution
mode:

1	The aim is to specify/measure some QoS metrics right?.  To be
strictly accurate however, what is being discussed here are Network
Performance (NP) metrics and not QoS metrics.....former is
objective/absolute and relates to network behaviour irrespective of the
application/service supported by the network entity considered, whilst
latter is subjective/relative and depends on specific application/service
supported by the network.  This is something well understood in Telco-land
for many years.  So for the rest of this mail I am going to refer to NP
metrics.

2	If one has NP metrics one really needs objectives that have to
met....else why bother specifying them and measuring them?

3	If one has objectives then one needs to understand how these are
allocated to partitions of networks.  That is, if there is some end-end
objective X say for some metric Y say then one needs to understand just
exactly what "end-end" means, eg 1km or 1/2-way round the world?  The normal
way to tackle this is to define some worst-case global HRX (Hypothetical
Reference Connection) and agree (i) the metrics, (ii) the end-end objectives
per metric and (iii) a fair way of allocating them to subnetwork
partitions.....noting that local access, national transit and international
transit usually have different allocation requirements.  If we don't have
such a model and method of fair apportionment then we are going to create
inter-operating problems for service providers....I think this is obvious.

4	Having got this far, it will still all come to nought unless there
is an agreed methodology of 'how' to measure such NP metrics.  The first
question to be answered is 'over what time periods are such NP
metrics/objectives valid?'  Clearly, if a network is broken its pointless
measuring delay, loss, errors, etc.  So a further pre-requisite that has to
be in place is the notion of 'up' and 'down' states for the network entity
considered.  Let's assume we had managed to sort this however.....so we now
have a situation where a network could be down for 99% of total time and up
for only 1% of total time, but during that 1% of up-time it met it's NP
objectives.  Clearly this is a nonsense situation.  So what I am saying here
is that we also need metrics/objectives that control up/down states *before*
we can consider metrics/objectives that control the NP of the up-state.
These '(un)availability' metrics/objectives are generally far more important
to SPs and customers than NP metrics/objectives.....and as I say, the latter
have no definition base without the former being in place 1st anyway.  Note
also that (un)availability state entry/exit criteria are in turn critically
dependent on all relevant defects being identified with their own entry/exit
criteria and consequent actions. So where are these defined per technology
of interest?
{Aside - It's not generally a good idea, if you can avoid it, to make
(un)availability entry/exit criteria a function of NP metrics.  There is an
obvious circular issue here, but the main reason I say this is one of
simplicity.....it can get extremely complex if the (un)availability
entry/exit criteria are a function of loss/delay/errors.}
Note - Some of you reading this will be aware that I/others have sorted this
lot out for the MPLS p2p case in Y.1711.  So at least this technology does
have a sound basis from which meaningful NP metrics/objectives could now be
specified/measured.  

5	One final quite important point......

Networks are vertically layered in a client/server sense as explained in
G.805, and they are also partitioned in a horizontal sense within a single
layer....this was the point I made above wrt apportioning end-end objectives
to smaller entities.  There are commercial and operational ownership issues
here in both the vertical and horizontal partitioning senses, ie different
domains own/operate different layered networks or partitions thereof.  So
there are commercial service level contracts that apply between different
organisations that have to be respected.  This makes the stuff I am talking
about above not an academic exercise, but something that is fundamentally
important to address.  AFAIK, much of this stuff is either being ignored or
glossed-over in much of the work I am seeing....esp in PWE3.  Speaking as a
service provider, this is really not satisfactory.

regards, Neil

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: 10 September 2002 03:26
> To: Tom Scott
> Cc: te-wg@ops.ietf.org
> Subject: Re: time tracing utility
> 
> 
> At 09:21 PM 9/9/2002 -0400, Tom Scott wrote:
> >In a thread on the CCAMP list regarding 
> draft-ietf-ccamp-tracereq-00.txt,
> >the authors indicated that a time-tracing application was beyond the
> >scope of the draft. Is there any interest in the TE WG for 
> such a utility,
> >as applied to the delay-based metric suggested in section 2 of
> >draft-ietf-tewg-te-metric-igp-01.txt:
> >
> >   In current MPLS TE deployments, network administrators often want
> >   Constraint Based Routing of TE LSPs carrying data traffic to be
> >   based on the same metric as the metric used for Shortest Path
> >   Routing. Where this is the case, this practice allows the 
> Constraint
> >   Based Routing algorithm running on the Head-End LSR to use the IGP
> >   metric advertised in the IGP to compute paths for data TE LSPs
> >   instead of the advertised TE metric. The TE metric can 
> then be used
> >   to convey another metric (e.g. a delay-based metric) which can be
> >   used by the Constraint Based Routing algorithm on the Head-End LSR
> >   to compute path for the TE LSPs with different requirements (e.g.
> >   Voice TE LSP).
> >
> >The management model in RFC 3290/89 describes ten "datapath 
> elements" and
> >"traffic conditioning blocks" that are constructed from the 
> elements. Is
> >it possible to use these elements (and TCBs?), along with the metric
> >recommendations of the IPPM WG, to define a time-tracing utility that
> >measures not only where traffic travels but also the time 
> that packets
> >take to travel from A to B, where the endpoints of interest 
> are nodes or
> >"functional groupings" on any layer or components such as 
> the datapath
> >elements in any of those nodes?
> >
> >If this is out of scope for the TE WG, I would be grateful 
> to anyone who
> >could refer me to publications on this topic.
> 
>          My question would be whether such a standard 
> mechanism/metrics
> is/are necessary.  As you point out, for TE that information could be 
> automatically
> fed back into the routing protocols used to flood TE 
> information and thus 
> govern the
> signaling (or re-signaling) of TE tunnels that do not behave 
> correctly.  However,
> I will point out that other mechanisms exist for measuring 
> the RTT/jitter of
> of a tunnel such as GTTP, LSP ping and automated versions of these.
> The information gathered can then be fed into the TE control 
> software on the
> head-end LSR to determine whether or not the tunnel is truly 
> meeting the
> SLA for the tunnel and/or whether an alternative (perhaps 
> more conforming)
> path option chosen.  Although the feedback mechanism is not 
> built-into the
> signaling software, it is certainly possible (and being 
> done). I am just 
> not so sure
> that anyone is clamoring for a more standard way of achieving 
> this other than
> what is being provided today.  It would be interesting to 
> hear from service 
> providers
> on this topic.
> 
>          --Tom
> 
> 
> 
> 
> --------------------------------------------------------------
> ----------
> Mathematics is the supreme nostalgia of our time. 
> 
>