Subject: RE: Re: Comments/ questions to draft-riegel-pwe3-tdm-requi rements-01.txt

From: [email-masked]
Date: Sat, 1 Feb 2003 17:39:21 -0000

Rick,   please see remark below.  regards, Neil

Rick Osteen wrote > Sent: 01 February 2003 12:45
> 
> I believe that some requirement regarding delay is important 
> for it to be
> attractive and useful to use. The first thought in the 
> service provider's
> mind is considering if the actual "gazinta gazada"(a.k.a goes 
> into, goes out
> of) works. The second is "Is it useful" or is it just not 
> going to be a good
> customer experience.
> The bar for any data packet and it's delay has been raised. 
> There are more
> and more people aware of delay and are wanting SLA's to hold 
> the service
> provider's accountable. Customers, residential and business, 
> are expecting
> money back if performance isn't up to par.
NH=> Quite so.  And as an operator this is very important to me.  However, I
must be able to properly *fault-manage* the network properly first (ie auto
defect detection/handling based on consistent defect entry/exit criteria and
consequent actions).  Delay/loss, or indeed any QoS metrics/objectives, are
of far less importance.  Further, any QoS metric measurements are only
meaningful when the network (or at least the PW in question here) is in the
available state....so one needs to define what this is in terms of
entry/exit criteria and consequent actions too (one of which, based on what
I have just observed, is stopping/starting QoS metric measurements on
entering/leaving the unavailable state).

There is an obvious logical ordering here:
-	define defects and their auto detection/handling 1st
-	then, based on above (ie persistency of defects), define
availability/unavailabilty.....note these need their own SLAs which are
disjoint from QoS SLAs;
-	than, and only then, can you sensibly define QoS SLAs since these
are only relevant to the available state.

Please read Y.1710/Y.1711, this is what is required for the fault-management
of MPLS p2p LSPs, esp when carrying arbitrary clients (availability is also
defined in here).  These Recs are based on the above logic. 
<snipped>

---

From: Max Riegel <[email-masked]>
Date: Mon, 03 Feb 2003 17:34:47 +0100

At 31.01.2003 16:18 +0100, Shahram Davari wrote:

> > GENERAL -The document specifies (section 2) the need to put special
> > emphasis on minimization of one-way delay. End-2-end delay (that
> > actually is the sum of packetiztion delay, network delay and delay
> > introduced by the jitter buffer] is important paramater for network
> > designer. I would propose to include the requirement for n x DS0 and n
> > x VC-x services - end-2-end delay should be not depend upon the value
> > of n.
>
>I don't think such a requirement is needed. Not only such requirement
>makes the design of the PW box more complicated, but also due to
>variable overhead it makes the capacity planning next to impossible.
>Also a few msec differences won't be noticeable by the end user.
>Remember we are not trying to perfectly emulate TDM networks.
>IP networks have characteristics that needs to be considered.

Shahram, I agree with you that we should not include requirements for 
end-to-end delay minimization. PWE3 deals with emulation edge-to-edge and 
it it our intention to design a protocol for use edge-to-edge.

Edge-to-edge implies that there might be several emulated circuits in line 
thus delay minimization for edge-to-edge is even becoming a more important 
issue. If a few ms might be tolerable end-to-end, n-times a few ms might 
become critical for the service transported over emulated TDM circuits. I 
didn't found a way yet how to restrict the repeated use of emulated TDM 
circuits in a real network.

I do not understand: "also due to variable overhead it makes the capacity 
planning next to impossible." Can you explain your meaning a little bit more.

Bye
Max

---

From: Shahram Davari <[email-masked]>
Date: Mon, 3 Feb 2003 08:50:47 -0800

Max,

> become critical for the service transported over emulated TDM 
> circuits.

Are you suggesting that the delay is proportional to the number of
emulated circuits (n)?

> planning next to impossible." Can you explain your meaning a 

I think you agree that using fixed delay edge-to-edge means each PWs will have different packet sizes. Since the header size is the same in all of them, therefore the % of overhead would be different between PWs. For example if a PW is carrying a single DS0, and assuming a packetization delay budget of 5 msec you could encapsulate max 40 bytes of data in the packet. Assuming a IP/UDP/RTP/IW header (44 bytes) we would have a BW efficiency of 50%. Now if another PW is carrying a single T1, then a max of 960 bytes could be carried in the packet which gives us BW efficiency of 95%.

So the service provider is unable to determine how much BW a certain amount of TDM traffic it can generate. Off course, it can reserve 2x BW and under-subscribe the network !

Yours,
-Shahram

---

From: Shahram Davari <[email-masked]>
Date: Mon, 3 Feb 2003 09:12:27 -0800

> If you are puting them not parallel but in sequence, you 
> might end up with 
> n-times the delay.

What do you mean by putting them in sequence and not parallel? All
WAN/MAN communication links are sequential (there is no parallel bus here).
I still can't understand your point. Could you please give an example.

> >I think you agree that using fixed delay edge-to-edge means 
> each PWs will 
> >have different packet sizes. Since the header size is the 
> same in all of 
> >them, therefore the % of overhead would be different between 
> PWs. For 
> >example if a PW is carrying a single DS0, and assuming a 
> packetization 
> >delay budget of 5 msec you could encapsulate max 40 bytes of 
> data in the 
> >packet. Assuming a IP/UDP/RTP/IW header (44 bytes) we would 
> have a BW 
> >efficiency of 50%. Now if another PW is carrying a single 
> T1, then a max 
> >of 960 bytes could be carried in the packet which gives us 
> BW efficiency 
> >of 95%.
> >
> >So the service provider is unable to determine how much BW a certain 
> >amount of TDM traffic it can generate. Off course, it can 
> reserve 2x BW 
> >and under-subscribe the network !
> 
> A service provider should know which circuits he is selling 
> to customers, 
> e.g. 7x DS0, 3x T1. It takes only simple mathematics to get 
> exact figures 
> of total bandwidth allocation, even if the overhead of the particular 
> circuits is different.
>

But the problem is that a service provider who has, let say allocated
10% of its core BW to CES, can't compute before hand how many DS0 it can
carry in that 10%. Computing real time is not a problem, planning is difficult.

Yours,
-Shahram

---

From: Max Riegel <[email-masked]>
Date: Mon, 03 Feb 2003 18:03:02 +0100

>Are you suggesting that the delay is proportional to the number of

If you are puting them not parallel but in sequence, you might end up with 
n-times the delay.

>I think you agree that using fixed delay edge-to-edge means each PWs will 
>have different packet sizes. Since the header size is the same in all of 
>them, therefore the % of overhead would be different between PWs. For 
>example if a PW is carrying a single DS0, and assuming a packetization 
>delay budget of 5 msec you could encapsulate max 40 bytes of data in the 
>packet. Assuming a IP/UDP/RTP/IW header (44 bytes) we would have a BW 
>efficiency of 50%. Now if another PW is carrying a single T1, then a max 
>of 960 bytes could be carried in the packet which gives us BW efficiency 
>of 95%.
>
>amount of TDM traffic it can generate. Off course, it can reserve 2x BW 

A service provider should know which circuits he is selling to customers, 
e.g. 7x DS0, 3x T1. It takes only simple mathematics to get exact figures 
of total bandwidth allocation, even if the overhead of the particular 
circuits is different.

Bye
Max