Subject: Comments on draft-shah-pwe3-PW-Qos_Signalling-00

From: [email-masked]
Date: Thu, 29 Jul 2004 17:25:52 +0100

Himanshu,

I read your draft with interest, and have some initial comments as follows:

The QoS TLV contains traffic parameters (traffic rates and associated
tolerances), not QoS requirements (loss, delay etc), so I think it should
be called Traffic Parameters or Traffic Descriptor TLV.

The uses stated in section 6 for this TLV are unclear. The draft states
that it is to signal tail end (egress) AC traffic parameters to the head
end
(ingress) PE. In the case of ATM ACs, the TLV does not convey service
category or conformace definition information, so it cannot be used for
policing by the head end PE, or selection of the appropriate PSN tunnel (it
is not clear how this helps anyway as there is a N:1 relationship between
ACs and PWs, not 1:N). If it could be used to configure the policer at the
head end PE, this would not guarantee that traffic would pass a policer at
a downstream AC because cell concatenation on the PW could cause the burst
tolerance stated in the traffic contract for the ATM connection to be
exceeded. Traffic may still need to be shaped from the PW to the tail AC.

In general, I think this might be useful a configuration check between the
2 ACs, but it is not to me clear if it enables the other stated uses to be
achieved.

Thanks,

Matthew

---

From: [email-masked]
Date: Fri, 30 Jul 2004 08:53:21 +0100

Matthew...please see below.....but let me make it clear these comments
are not specifically aimed at you....my hope is folks take note of them
and do think seriously about.

> The QoS TLV contains traffic parameters (traffic rates and 
> associated tolerances), not QoS requirements (loss, delay 
> etc), so I think it should be called Traffic Parameters or 
> Traffic Descriptor TLV.
NH=> {Preface - What follows may sound initially picky, but we are
getting very concerned at the amount of flawed/poor network architecture
we are seeing and the use of vague/loose terminology.  This is already
causing us operational problems with the limited stuff deployed and we
don't see things improving given the current direction.....in fact its
my view things are actually going to get worse.  For example, if/when we
ever get to the stage of trying to interwork layer networks owned by
different operators using some of the technologies being discussed here
(both in a vertical client/server sense and a horizontal same-layer
sense, ie across an E-NNI) then we will require a precise specification
that may have contractual obligations.  So there are not only technical
considerations but also commercial considerations (and for some
operators possibly even regulatory considerations) here......however,
the former needs to be right to enable the latter.}

QoS is a subjective concept.  It represents a particular
application's/user's perception of 'quality' for a given set of
(objective) Network Performance (NP) impairments. For a fixed level of
NP impairments (across loss/error/delay metrics) different
applications/users can have very different perceptions of 'quality'.  So
it is the NP parameters that must be specified.  However, this alone is
not sufficient.......

Operators will need to be able to unambiguously measure the NP
parameters at key points, eg NNIs and trail termination points, to be
sure they are meeting contractual SLAs.  So this immediately means there
is a requirement for the following:
-	specification of a HRX (Hypothetical Reference Connection) with
end-end objectives and their apportionment to partitions of this HRX, ie
the impairment allowance an operator has to stay within over some agreed
measurement period.
-	NP measurements are only meaningful in the up-state and their
measurement against NP SLAs must be suspended in the down-state.....this
means we need a clear specification of the (un)availability metric
(before we can even consider the NP measurement) and this also requires
its own SLA;
-	(un)availability is, in turn, predicated on the specification of
defects.  These are *different* for each network mode as I have tried to
point out in past mails (though they should be consistent within each
mode, *provided* the arch constraints of the mode are not violated).
Defects per mode need defining with clear entry/exit criteria and
consequent actions.  This is a must-have requirement anyway simply for
day-day operational management.

None of the above is being properly addressed in this WG....and I am not
sure it ever will/can be.  So there is no basis to even start to talk
about 'QoS' or more accurately NP.  Its quite clear IMO that there will
be downstream problems arising when operators want to interwork and have
to meet contractual SLAs.  
> 
> The uses stated in section 6 for this TLV are unclear. The 
> draft states that it is to signal tail end (egress) AC 
> traffic parameters to the head end
> (ingress) PE. In the case of ATM ACs, the TLV does not convey 
> service category or conformace definition information, so it 
> cannot be used for policing by the head end PE, or selection 
> of the appropriate PSN tunnel
NH=> Quite.  But where is the NP/(un)availability/defect specifications
of the PSN technologies defined anyway?  If you don't have this then how
on earth do you think one can make meaningful 'mappings' here?  None of
this stuff stands-up to any critical examination.

> (it is not clear how this helps 
> anyway as there is a N:1 relationship between ACs and PWs, 
> not 1:N).
NH=> Right again.  This also gives one a big hint that a server layer's
transfer NP must be meet/exceed the client's NP transfer NP
requirements.  However, there are no rules for this between the 3 modes
as yet, nor indeed how many such client/server transitions between
different modes can be allowed in some HRX.

> If it could be used to configure the policer at the 
> head end PE, this would not guarantee that traffic would pass 
> a policer at a downstream AC because cell concatenation on 
> the PW could cause the burst tolerance stated in the traffic 
> contract for the ATM connection to be exceeded.
NH=> Right again.....and this is exactly the point above, ie the server
layer's transfer performance must be better than the client's......and
none of this is specified.

Note - I am not saying any of the above is easy.  The key point I am
making however is this:  If the technology/architecture has not
specified (or cannot specify) its defects up-front then the rest (ie
availability/NP SLAs) have no chance of being properly addressed later.

Regards, Neil

> Traffic may 
> still need to be shaped from the PW to the tail AC.
> 
> In general, I think this might be useful a configuration 
> check between the 2 ACs, but it is not to me clear if it 
> enables the other stated uses to be achieved.
> 
> Thanks,
> 
> Matthew
> 
> 
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>