Subject: Re: [OPSAWG] Requirements for IP/MPLS network transmission interruption duration

From: "Fan Peng" <[email-masked]>
Date: Mon, 19 Mar 2012 21:59:47 +0800

Hi all,

Any feedback about this memo?

I think I’d better point out the purpose of this I-D straightforward. We
are not considering the outage time of IP/MPLS layer need to be more
strictly limited, but we want to reveal the fact that longer outage time is
tolerable. Although the industry may have some existing perspectives on the
matter of interruption duration – for example sub-50ms-outage-time
requirement for physical transport layer – we think the requirement for
IP/MPLS layer can be alleviated to some extent as long as upper-level
service connection is not affected to be broken. To be more specific, we
consider IP interruption duration of 3 sec is ok for softswitch voice.

There is no consensus right now in the industry on interruption duration for
IP/MPLS layer. We are hoping that we can discuss this problem  and finally
reach an agreement on requirement for IP/MPLS interruption duration. We hold
the opinion that sub-50ms requirement is not necessary for IP, and wish to
hear comments from all of you.

Best regards,

Fan Peng

发件人: fanpeng [mailto:[email-masked]] 
发送时间: 2012年3月12日 23:24
收件人: [email-masked]'; 'Bradner, Scott'; '<[email-masked]>';
'<[email-masked]>'
抄送: 李连源 ([email-masked])
主题: Requirements for IP/MPLS network transmission interruption duration

Greetings all,

We have recently submitted a draft on transmission interruption duration
(draft-fan-opsawg-transmission-interuption-00
<http://datatracker.ietf.org/doc/draft-fan-opsawg-transmission-interuption/>
). We felt it necessary to make requirements for the interruption duration
since there is no consensus on it yet in the industry. We primarily analyzed
interruption criteria for softswitch voice, and research on LTE backhaul and
other kinds of service scenarios has been in progress.

We would like to hear from you feedbacks about this draft, e.g. whether or
not there should be such requirements or methodology for the analysis. Any
comment on it will be appreciated.

The following is a brief introduction:

Today's IP/MPLS network is widely used as a bearing network to carry
diversified packet switched services. The transmission qualities of these
services are closely related to the performance of bearing layers, as
network failure, delay, congestion and other abnormities will inevitably
bring about service interruption and user perception degradation. However,
there is no consensus in the industry on transmission interruption for
IP/MPLS network up to now.  This memo studies relationships between service
performance and transmission interruption duration in several scenarios, and
is intended to reach a list of requirements for these interruption duration
criteria.

Best regards,                                 

Fan Peng

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 19 Mar 2012 15:20:17 +0100

Hi Fan Peng,

Question - How can a voice application be sustained when the IP interruption duration is 3 sec? Typically the acceptable delay in two-way voice calls is considered to be max 150 msec. If traffic is interrupted for 3 sec you either lose 100% of the traffic for the 3 sec (also inacceptable) or you buffer and register a delay way more than the acceptable numbers. 

Thanks and Regards,

Dan

(asking as a contributor)

From: [email-masked] [mailto:[email-masked]] On Behalf Of Fan Peng
Sent: Monday, March 19, 2012 4:00 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [OPSAWG] Requirements for IP/MPLS network transmissioninterruption duration

Hi all,

I think I’d better point out the purpose of this I-D straightforward. We are not considering the outage time of IP/MPLS layer need to be more strictly limited, but we want to reveal the fact that longer outage time is tolerable. Although the industry may have some existing perspectives on the matter of interruption duration – for example sub-50ms-outage-time requirement for physical transport layer – we think the requirement for IP/MPLS layer can be alleviated to some extent as long as upper-level service connection is not affected to be broken. To be more specific, we consider IP interruption duration of 3 sec is ok for softswitch voice.

There is no consensus right now in the industry on interruption duration for IP/MPLS layer. We are hoping that we can discuss this problem  and finally reach an agreement on requirement for IP/MPLS interruption duration. We hold the opinion that sub-50ms requirement is not necessary for IP, and wish to hear comments from all of you.

Best regards,

Fan Peng

发件人: fanpeng [mailto:[email-masked]] 
发送时间: 2012年3月12日 23:24
收件人: [email-masked]'; 'Bradner, Scott'; '<[email-masked]>'; '<[email-masked]>'
抄送: 李连源 ([email-masked])
主题: Requirements for IP/MPLS network transmission interruption duration

Greetings all,

We have recently submitted a draft on transmission interruption duration (draft-fan-opsawg-transmission-interuption-00 <http://datatracker.ietf.org/doc/draft-fan-opsawg-transmission-interuption/> ). We felt it necessary to make requirements for the interruption duration since there is no consensus on it yet in the industry. We primarily analyzed interruption criteria for softswitch voice, and research on LTE backhaul and other kinds of service scenarios has been in progress.

We would like to hear from you feedbacks about this draft, e.g. whether or not there should be such requirements or methodology for the analysis. Any comment on it will be appreciated.

Today's IP/MPLS network is widely used as a bearing network to carry diversified packet switched services. The transmission qualities of these services are closely related to the performance of bearing layers, as network failure, delay, congestion and other abnormities will inevitably bring about service interruption and user perception degradation. However, there is no consensus in the industry on transmission interruption for IP/MPLS network up to now.  This memo studies relationships between service performance and transmission interruption duration in several scenarios, and is intended to reach a list of requirements for these interruption duration criteria.

Best regards,                                 

Fan Peng

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Mon, 19 Mar 2012 11:07:26 -0700

Greetings,

<speaking as an individual contributor>

	I think this draft, if it is properly structured, and supported, could be useful.  Today everyone's default answer to "how fast do you want to restore" is 50ms, as that is the current "standard."  However, that 50ms horizon does add cost and complexity in some cases.  A really bottomed out and supported draft that covers many use cases could be quite useful.

Chris

On 19Mar2012, at 06.59, Fan Peng wrote:

> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

--  
李柯睿
Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc
Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf
Check my calendar availability: https://tungle.me/cdl

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 19 Mar 2012 20:48:44 -0000

<also as an individual>

I would also like to support the concept of this draft. Not only have we followed the 50ms mantra for a long time, but there are arguments that it wasn't a number picked for best user-centric reasons.

It would be great to know what the real requirements are in IP/MPLS networks, and maybe understand how these relate to different services that are being carried. The example of VoIP has already been given, and pseudowires may also drive switchover time. But other services are surely less likely to need such rapid protection.

Another factor will, or course, depend on whether the service type is or can be known. In the core of an IP/MPLS network this may be hard. at the edges (where end-to-end protection is done?) it may be easier.

Cheers,
Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Christopher LILJENSTOLPE
> Sent: 19 March 2012 18:07
> To: Fan Peng
> Cc: [email-masked]; [email-masked]
> 	I think this draft, if it is properly structured, and supported, could be
> useful.  Today everyone's default answer to "how fast do you want to restore" is
> 50ms, as that is the current "standard."  However, that 50ms horizon does add
> cost and complexity in some cases.  A really bottomed out and supported draft
> that covers many use cases could be quite useful.
> 
> Chris
> 
>

---

From: "Fan Peng" <[email-masked]>
Date: Tue, 20 Mar 2012 17:10:29 +0800

Hi Dan,

Thanks for your question.

What we talked about softswitch impairment in this memo focused mainly on
control plane and barely on user plane. A voice connection can be sustained
as long as the connection on control plane is not released, which is
achieved by some signal interaction detection and timeout mechanism.

When we talk about “delay” we usually refer to two kinds of delay:
connection delay and transmission delay (though I am not quite sure about
these English equivalent terms). Connection delay measures the period needed
stating when a call is initiated and finishing when the called party rings;
while transmission delay, explicitly, measures how long the opposite party
has to wait to hear me after I speak a sentence. I think by 150 msec delay
in your letter you intended to mention the transmission delay?

Connection delay, explained in our document,  involves many signaling
processes thus usually consumes several seconds on average, far longer than
transmission delay. Transmission delay is actually one of the design
criteria that have to be considered during the network planning phase. It
sets quality the network has to guarantee in the normal working state, but
only in the normal working state. If a network failure occurs, the previous
normal state criteria are highly unlikely to be satisfied, with user
perception suffering also probable. So if IP layer breaks out, the user will
likely to experience a short period of voice delay, intermittency, or even
100% loss, just as the circumstances we may encounter in everyday life when
stepping into an elevator or underground garage or under an overpass and
stepping out shortly after. So as long as the IP lay recovers quickly,
connection can still be remained. Although this may harm user perception a
little bit, we think it is better than complete breakoff and dialing again.

In order to avoid this user perception harm, the IP bearing network needs to
be more robust, which leads to another aspect of network operation and
management focusing on network availability with criteria like
unavailability, failure rate, MTTR, MTBF and so on. What we concern is
actually the ability of IP layer to tolerate abnormalities after a network
failure indeed occurs. In summary, these can be considered two points of
view or levels of problem.

Please let me know if I didn’t make myself clear enough:) I will try to
initiate discussion with my colleagues specialized in softswitch and hope to
get more detailed information.

Regards,

Fan Peng

发件人: Romascanu, Dan (Dan) [mailto:[email-masked]] 
发送时间: 2012年3月19日 22:20
收件人: Fan Peng; [email-masked]
抄送: [email-masked]
主题: RE: [OPSAWG] Requirements for IP/MPLS network transmissioninterruption
duration

Hi Fan Peng,

Question - How can a voice application be sustained when the IP interruption
duration is 3 sec? Typically the acceptable delay in two-way voice calls is
considered to be max 150 msec. If traffic is interrupted for 3 sec you
either lose 100% of the traffic for the 3 sec (also inacceptable) or you
buffer and register a delay way more than the acceptable numbers. 

Thanks and Regards,

Dan

 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Fan Peng
Sent: Monday, March 19, 2012 4:00 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [OPSAWG] Requirements for IP/MPLS network
transmissioninterruption duration

Hi all,

Best regards,

Fan Peng

Greetings all,

 

Best regards,                                 

Fan Peng

---

From: "Fan Peng" <[email-masked]>
Date: Tue, 20 Mar 2012 17:54:16 +0800

Dear Christopher and Adrian,

Thanks for your kind review.

This document is far from complete as we only (preliminarily) finished the illustration on softswitch which is mainly based on our previous research work on China Mobile's commercial network. We intend to extend our concern to other services especially LTE backhaul. However, it is not easy to analyze this kind of issue, and it may take months to finish research on a single type of service. So help from industry is highly appreciated.

I think Adrian's question can be interpreted as "whether the IP layer is aware of what kinds of serves it is carrying and how it defines requirement for multiple services?" We planned to complete first requirements for different services so we didn't look deep into global issues like this. But I do think this issue is a problem to be solved and we will pay attention to this.

Best wishes,

Fan Peng

-----邮件原件-----
发件人: Adrian Farrel [mailto:[email-masked]] 
发送时间: 2012年3月20日 4:49
收件人: 'Fan Peng'
抄送: [email-masked]; [email-masked]
主题: RE: [OPSAWG] Requirements for IP/MPLS network transmission interruption duration

<also as an individual>

Cheers,
Adrian

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Christopher LILJENSTOLPE
> 	I think this draft, if it is properly structured, and supported, 
> could be useful.  Today everyone's default answer to "how fast do you 
> want to restore" is 50ms, as that is the current "standard."  However, 
> that 50ms horizon does add cost and complexity in some cases.  A 
> really bottomed out and supported draft that covers many use cases could be quite useful.
> 
> Chris
> 
> 
> > I think I’d better point out the purpose of this I-D 
> > straightforward. We are not considering the outage time of IP/MPLS 
> > layer need to be more strictly limited, but we want to reveal the 
> > fact that longer outage time is tolerable. Although the industry may 
> > have some existing perspectives on the matter of interruption 
> > duration – for example sub-50ms-outage-time requirement for physical 
> > transport layer – we think the requirement for IP/MPLS layer can be 
> > alleviated to some extent as long as upper-level service connection 
> > is not affected to be broken. To be more specific, we consider IP interruption duration of 3 sec is ok for softswitch voice.
> >
> >
> >
> > There is no consensus right now in the industry on interruption 
> > duration for IP/MPLS layer. We are hoping that we can discuss this 
> > problem  and finally reach an agreement on requirement for IP/MPLS 
> > interruption duration. We
> hold
> > the opinion that sub-50ms requirement is not necessary for IP, and 
> > wish to hear comments from all of you.
> >
> >
> >
> > Best regards,
> >
> >
> >
> > Fan Peng
> >
> >
> >
> >
> >
> > <http://datatracker.ietf.org/doc/draft-fan-opsawg-transmission-inter
> > uption/> ). We felt it necessary to make requirements for the 
> > interruption duration since there is no consensus on it yet in the 
> > industry. We primarily analyzed interruption criteria for softswitch 
> > voice, and research on LTE backhaul and other kinds of service 
> > scenarios has been in progress.
> >
> >
> >
> > We would like to hear from you feedbacks about this draft, e.g. 
> > whether or not there should be such requirements or methodology for 
> > the analysis. Any comment on it will be appreciated.
> >
> >
> >
> > diversified packet switched services. The transmission qualities of 
> > these services are closely related to the performance of bearing 
> > layers, as network failure, delay, congestion and other abnormities 
> > will inevitably bring about service interruption and user perception 
> > degradation. However, there is no consensus in the industry on 
> > transmission interruption for IP/MPLS network up to now.  This memo 
> > studies relationships between service performance and transmission 
> > interruption duration in several scenarios, and is intended to reach 
> > a list of requirements for these interruption duration criteria.
> >
> >
> >
> >
> >
> > Best regards,
> >
> >
> >
> > Fan Peng
> >

---

From: "George, Wes" <[email-masked]>
Date: Tue, 20 Mar 2012 09:47:54 -0400

> I think Adrian's question can be interpreted as "whether the IP layer is aware
> of what kinds of serves it is carrying and how it defines requirement for
> multiple services?"

[WEG] I'd put it in slightly different terms.
Today, many people build IP networks to carry things that used to live directly on SONET/SDH. Those applications are sometimes designed with SONET/SDH's performance envelope in mind (sub-millisecond fault detection, 50ms restoration), and so applications expect an equivalent performance envelope from an IP network, which is costly, and starts to drive more and more complex IP networks (including things like MPLS TE).

Instead, we need to produce guidance for the application community about the typical/average and best-possible-case performance envelope for a properly designed IP network, both a network using standard IP with few optimizations, and one that employs things to improve detection, convergence, and restoration times, such as IP or MPLS FRR, or TE. The idea is that they need to design to what the network is capable of delivering, rather than the other way around. Then we can discuss the user-experience requirements for different types of applications, including voice, video, real-time web apps, etc, as well as the needs of extreme cases like the securities industry, which value low latency over all else.

Thanks

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 20 Mar 2012 07:46:44 -0700

> > From: [email-masked] [mailto:[email-masked]] On
Behalf Of
> Today, many people build IP networks to carry things that used to live
directly on SONET/SDH. Those applications are sometimes designed with
SONET/SDH's performance envelope in mind (sub-millisecond fault detection,
50ms restoration), and so applications expect an equivalent performance
envelope from an IP network, which is costly, and starts to drive more and
more complex IP networks (including things like MPLS TE).
>
> Instead, we need to produce guidance for the application community about
the typical/average and best-possible-case performance envelope for a
properly designed IP network, both a network using standard IP with few
optimizations, and one that employs things to improve detection,
convergence, and restoration times, such as IP or MPLS FRR, or TE. The idea
is that they need to design to what the network is capable of delivering,
rather than the other way around. Then we can discuss the user-experience
requirements for different types of applications, including voice, video,
real-time web apps, etc, as well as the needs of extreme cases like the
securities industry, which value low latency over all else.
> Wes George

+1 for Wes's approach.

We have been chasing 50ms for years, and it is not the right goal.
I believe the goal should be driven by what is reasonably achievable in a
well run IP network, and applications can take that feedback as a design
goal  for applications that run on a reasonable and well run network.
Additional guidance about exponential back off of signalling would be
nice.... ah and a note about how the term IP network = ipv6.

I got a whole list of guidance for LTE back haul  :)

But this is scope creep

Cb

> This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject to
copyright belonging to Time Warner Cable. This E-mail is intended solely
for the use of the individual or entity to which it is addressed. If you
are not the intended recipient of this E-mail, you are hereby notified that
any dissemination, distribution, copying, or action taken in relation to
the contents of and attachments to this E-mail is strictly prohibited and
may be unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any copy of
this E-mail and any printout.