Subject: Re: [Diffserv] A question on a PDB definition

From: Mikhail Smirnov <[email-masked]>
Date: Wed, 21 Feb 2001 21:39:47 +0100 (MET)

On Wed Feb 21 21:12:58 2001 Hermann DE MEER wrote:
> Brian,
> 
> this is exactly what I mean.
> 
> But I am suggesting to go  (at least) one step further:
> not only to express the parameter as percentiles but to
> include a characterization of such an event, which may
> be called a QoS segment fault, and its admissible impact on the
> traffic aggregate into the PDB spec. In its weakest form, simply
> a more or less informative indication would be useful
> 
> The significance of that is that e2e QoS may still be achievable
> with (well-defined)  QoS segment faults if appropriate tolerance measure were
> taken on the service level or somewhere else.

IMO, this "somewhere else" was well defined in IntServ as
"characterisation point", per path. In DiffServ it will be useful
to have such points  per domain (and per service?)

> 
> I know that the service def is not part of the PDB itself, but the 
> inclusion of the concept of QoS segment faults into the PDB may
> be useful ("later on") for service creation.
> 
> Otherwise you simply would have an undefined behavior in case
> of that rare event which may, nevertheless, occur more or less regularly. This 
> would seem quite undesirable and may break the whole chain more often than not.
> (and more often than perhaps necessary)
> 
> 
> --Hermann
> 
> 
> 
> 
> 
> > Hermann,
> > 
> > Yes indeed - the Internet is a queuing system so of course it is not perfect.
> > That's exactly why I expect the parameters on real PDBs to be expressed
> > as percentiles. Even if we can define absolute bounds for certain PHBs,
> > these certainly won't survive as edge2edge bounds. So, for example
> > a PHB with bounded jitter <J_h will lead to a PDB whose jitter is <J_d for P%
> > of the time. And J_d and P will be experimental values, not calculated.
> > Does that capture what you mean?
> > 
> >   Brian
> > 
> > Hermann DE MEER wrote:
<...>

cheers

Michael

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html