Subject: [sfc] Updated Draft on NSH Timstamping

From: "Browne, Rory" <[email-masked]>
Date: Thu, 2 Jun 2016 09:48:52 +0000

Hi all

Updated draft on this submitted. The new draft aims to better separate control and data plane functions.

This draft has 3 general applications

- measure VNF performance - ingress & egress time for a given subscriber flow - this is useful post SW upgrade for example
- measure Vlink performance, whether this is a local Vlink or spans different NFVI-PoPs
- measure E2E flow delay within a chain - With little overhead quickly identify performance problems

In general we see tight monitoring of latency becoming more important as we increase IoT integration in to the mobile networks for low latency applications.

We have coded and demonstrated this at NFV congress in April with positive feedback from operators and vendors on the usefulness of the approach.

Name:                  draft-browne-sfc-nsh-timestamp
Revision:              01
Title:                     Network Service Header Timestamping
Document date: 2016-06-01
Group:                  Individual Submission
Pages:                  20
URL:            https://www.ietf.org/internet-drafts/draft-browne-sfc-nsh-timestamp-01.txt

BR Rory

--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263

This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 6 Jun 2016 11:01:57 +0000

Hi All,

As one of the co-authors, we would highly appreciate your feedbacks about the draft.
Specifically, we would appreciate feedbacks about the question: is timestamping useful in SFC environments?

We believe that timestamping is indeed useful, for the applications Rory described below, as well as for other applications.

Would appreciate your feedbacks.

Cheers,
Tal.

From: sfc [mailto:[email-masked]] On Behalf Of Browne, Rory
Sent: Thursday, June 02, 2016 12:49 PM
To: [email-masked]
Cc: Jim Guichard (jguichar)
Subject: [sfc] Updated Draft on NSH Timstamping

Hi all

BR Rory

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Mon, 6 Jun 2016 13:16:25 +0000

Hi,

I had a couple of initial comments as result of a first glance at the text once Rory sent the message that were waiting for a more detail read, but since Tal asks, here they go as they are now…

I do believe timestamping can be a useful feature for SFC environments, especially in the case of measure E2E delays. We need to start seriously considering E2E communication properties in NFV and SFC, the sooner the better. So the consideration of timestamping as a potential technique for this has all my support.

Apart from this, there a few things that are not clear to me:

* First, why do you circumscribe the application to VNFs. Why would a PNF become unable to add timestamping?

* Second, I’d say the mention to the TSDB is completely out of scope. What the LTSN does with the timestamps should be completely open

* Third, the same happens to the ideas around the TSCP and the control mechanisms in general. I am not sure the definition of the TS Controller is needed at all and, all in all, it makes again assumptions about timestamping being one-to-one related to VNFs…

Be goode,

On 6 Jun 2016, at 13:01 , Tal Mizrahi <[email-masked]<mailto:[email-masked]>> wrote:

Hi All,

Cheers,
Tal.

To: [email-masked]<mailto:[email-masked]>

Hi all

- measure VNF performance – ingress & egress time for a given subscriber flow – this is useful post SW upgrade for example
- measure Vlink performance, whether this is a local Vlink or spans different NFVI-PoPs
- measure E2E flow delay within a chain – With little overhead quickly identify performance problems

BR Rory
_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 6 Jun 2016 19:00:14 +0000

I also believing having a timestamp is a good feature, but not sure if it is necessary to have both Ingress & egress timestamp on every packet. Also not necessary for every packet of a flow.

In addition, the following prerequisite is a too hard for deployed nodes to meet:

In order to guarantee metadata accuracy, all servers hosting VNFs
should be synchronized from a centralized stable clock. As PNFs do
not timestamp there is no need for them to synchronize. There are two
possible levels of synchronization:

Linda Dunbar

From: sfc [mailto:[email-masked]] On Behalf Of DIEGO LOPEZ GARCIA
Sent: Monday, June 06, 2016 8:16 AM
To: Tal Mizrahi
Cc: Browne, Rory; [email-masked]; Jim Guichard (jguichar)
Subject: Re: [sfc] Updated Draft on NSH Timstamping

Hi,

Be goode,

Hi All,

Cheers,
Tal.

Hi all

BR Rory

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]<mailto:[email-masked]>
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 6 Jun 2016 15:05:31 -0400

I would phrase it differently.
Being able to determine the latency of the actual path, and the latency 
through individual service functions, seems quite useful.
Paired timestamps may be the right way to do this.
There may be other ways as well.

Yours,
Joel

On 6/6/16 3:00 PM, Linda Dunbar wrote:
> I also believing having a timestamp is a good feature, but not sure if
> it is necessary to have both Ingress & egress timestamp on every packet.
> Also not necessary for every packet of a flow.
>
>
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *DIEGO LOPEZ GARCIA
> *Sent:* Monday, June 06, 2016 8:16 AM
> *To:* Tal Mizrahi
> *Cc:* Browne, Rory; [email-masked]; Jim Guichard (jguichar)
> *Subject:* Re: [sfc] Updated Draft on NSH Timstamping
>
>
>
> Hi,
>
>
>
> I had a couple of initial comments as result of a first glance at the
> text once Rory sent the message that were waiting for a more detail
> read, but since Tal asks, here they go as they are now…
>
>
>
> I do believe timestamping can be a useful feature for SFC environments,
> especially in the case of measure E2E delays. We need to start seriously
> considering E2E communication properties in NFV and SFC, the sooner the
> better. So the consideration of timestamping as a potential technique
> for this has all my support.
>
>
>
> * Second, I’d say the mention to the TSDB is completely out of scope.
> What the LTSN does with the timestamps should be completely open
>
>
>
> * Third, the same happens to the ideas around the TSCP and the control
> mechanisms in general. I am not sure the definition of the TS Controller
> is needed at all and, all in all, it makes again assumptions about
> timestamping being one-to-one related to VNFs…
>
>
>
> Be goode,
>
>
>
>
>
>     We believe that timestamping is indeed useful, for the applications
>     Rory described below, as well as for other applications.
>
>
>
>     *From:* sfc [mailto:[email-masked]] *On Behalf Of *Browne, Rory
>     *Sent:* Thursday, June 02, 2016 12:49 PM
>     *To:* [email-masked] <mailto:[email-masked]>
>     *Cc:* Jim Guichard (jguichar)
>     *Subject:* [sfc] Updated Draft on NSH Timstamping
>
>
>
>     Hi all
>
>
>
>     Updated draft on this submitted. The new draft aims to better
>     separate control and data plane functions.
>
>
>
>     - measure VNF performance – ingress & egress time for a given
>     subscriber flow – this is useful post SW upgrade for example
>
>     In general we see tight monitoring of latency becoming more
>     important as we increase IoT integration in to the mobile networks
>     for low latency applications.
>
>
>
>     We have coded and demonstrated this at NFV congress in April with
>     positive feedback from operators and vendors on the usefulness of
>     the approach.
>
>
>
>
>
>
>
>
>     [email-masked] <mailto:[email-masked]>
> e-mail: [email-masked] <mailto:[email-masked]>
> Tel:    +34 913 129 041
> Mobile: +34 682 051 091
> ------------------------------------------------------------------------
>
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud
> de la legislación vigente. Si ha recibido este mensaje por error, le
> rogamos que nos lo comunique inmediatamente por esta misma vía y proceda
> a su destrucción.
>
> The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution
> or copying of this communication is strictly prohibited. If you have
> received this transmission in error, do not read it. Please immediately
> reply to the sender that you have received this communication in error
> and then delete it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu
> destinatário, pode conter informação privilegiada ou confidencial e é
> para uso exclusivo da pessoa ou entidade de destino. Se não é vossa
> senhoria o destinatário indicado, fica notificado de que a leitura,
> utilização, divulgação e/ou cópia sem autorização pode estar proibida em
> virtude da legislação vigente. Se recebeu esta mensagem por erro,
> rogamos-lhe que nos o comunique imediatamente por esta mesma via e
> proceda a sua destruição
>
>
>
> [email-masked]

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 6 Jun 2016 19:08:12 +0000

Joel, 

Agree with you 100%. Like your description. 

Linda

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Monday, June 06, 2016 2:06 PM
To: Linda Dunbar; DIEGO LOPEZ GARCIA; Tal Mizrahi
Cc: Browne, Rory; [email-masked]; Jim Guichard (jguichar)
Subject: Re: [sfc] Updated Draft on NSH Timstamping

I would phrase it differently.
Being able to determine the latency of the actual path, and the latency through individual service functions, seems quite useful.
Paired timestamps may be the right way to do this.
There may be other ways as well.

Yours,
Joel

On 6/6/16 3:00 PM, Linda Dunbar wrote:
> read, but since Tal asks, here they go as they are now.
>
>
>
> I do believe timestamping can be a useful feature for SFC 
> environments, especially in the case of measure E2E delays. We need to 
> start seriously considering E2E communication properties in NFV and 
> SFC, the sooner the better. So the consideration of timestamping as a 
> potential technique for this has all my support.
>
>
>
> * Second, I'd say the mention to the TSDB is completely out of scope.
> mechanisms in general. I am not sure the definition of the TS 
> Controller is needed at all and, all in all, it makes again 
> assumptions about timestamping being one-to-one related to VNFs.
>
>
>
> Be goode,
>
>
>
>
>
>     - measure VNF performance - ingress & egress time for a given
>     subscriber flow - this is useful post SW upgrade for example
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su 
> destinatario, puede contener información privilegiada o confidencial y 
> es para uso exclusivo de la persona o entidad de destino. Si no es 
> usted. el destinatario indicado, queda notificado de que la lectura, 
> utilización, divulgación y/o copia sin autorización puede estar 
> prohibida en virtud de la legislación vigente. Si ha recibido este 
> mensaje por error, le rogamos que nos lo comunique inmediatamente por 
> esta misma vía y proceda a su destrucción.
>
> confidential information intended only for the use of the individual 
> or entity named above. If the reader of this message is not the 
> intended recipient, you are hereby notified that any dissemination, 
> distribution or copying of this communication is strictly prohibited. 
> If you have received this transmission in error, do not read it. 
> Please immediately reply to the sender that you have received this 
> communication in error and then delete it.
>
> utilização, divulgação e/ou cópia sem autorização pode estar proibida 
> em virtude da legislação vigente. Se recebeu esta mensagem por erro,

---

From: "Browne, Rory" <[email-masked]>
Date: Tue, 7 Jun 2016 08:33:19 +0000

Hi Linda

There are different modes supported, so ingress and egress on every packet is not mandated. The primary use of this draft is as a debug tool – so a very small set of flows per chain could be periodically measured E2E (FTSN timestamps, LTSN timestamps only) – Only after major delta would a more intrusive timestamping mode be used

“In addition, the following prerequisite is a too hard for deployed nodes to meet: “

- Can you elaborate on ‘too hard’?

BR Rory

From: Linda Dunbar [mailto:[email-masked]]
Sent: Monday, June 6, 2016 8:00 PM
To: DIEGO LOPEZ GARCIA <[email-masked]>; Tal Mizrahi <[email-masked]>
Cc: Browne, Rory <[email-masked]>; [email-masked]; Jim Guichard (jguichar) <[email-masked]>
Subject: RE: [sfc] Updated Draft on NSH Timstamping

Linda Dunbar

From: sfc [mailto:[email-masked]] On Behalf Of DIEGO LOPEZ GARCIA
Sent: Monday, June 06, 2016 8:16 AM
To: Tal Mizrahi
Cc: Browne, Rory; [email-masked]<mailto:[email-masked]>; Jim Guichard (jguichar)
Subject: Re: [sfc] Updated Draft on NSH Timstamping

Hi,

Be goode,

Hi All,

Cheers,
Tal.

Hi all

BR Rory

Dr Diego R. Lopez
Telefonica I+D

---

From: "Browne, Rory" <[email-masked]>
Date: Tue, 7 Jun 2016 08:35:15 +0000

Hi Diego,

I guess they could, but a very small percentage of PNFs support NSH today. We should clarify this though.

Noted re TSDB and TSCP

BR Rory

From: DIEGO LOPEZ GARCIA [mailto:[email-masked]]
Sent: Monday, June 6, 2016 2:16 PM
To: Tal Mizrahi <[email-masked]>
Cc: Browne, Rory <[email-masked]>; [email-masked]; Jim Guichard (jguichar) <[email-masked]>
Subject: Re: [sfc] Updated Draft on NSH Timstamping

Hi,

Be goode,

Hi All,

Cheers,
Tal.

Hi all

BR Rory

Dr Diego R. Lopez
Telefonica I+D