Subject: [Detnet] FW: New Version Notification for draft-zha-detnet-requirments-00.txt

From: zhayiyong <[email-masked]>
Date: Wed, 16 Mar 2016 09:10:48 +0000

Hi Folks,

Here is a requirements draft for your reading pleasure. The name may not be appropriated since the draft talks about some technical consideration on data plane, control plane and modeling. We take this one as an input for discussion. 

Cheers,
Yiyong Zha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, March 16, 2016 5:07 PM
To: 4c 69 61 6e 67 20 47 65 6e 67; Liang Geng; zhayiyong
Subject: New Version Notification for draft-zha-detnet-requirments-00.txt

A new version of I-D, draft-zha-detnet-requirments-00.txt
has been successfully submitted by Yiyong Zha and posted to the IETF repository.

Name:		draft-zha-detnet-requirments
Revision:	00
Title:		Deterministic Networking Requirements on Data and Control Plane
Document date:	2016-03-16
Group:		Individual Submission
Pages:		12
URL:            https://www.ietf.org/internet-drafts/draft-zha-detnet-requirments-00.txt
Status:         https://datatracker.ietf.org/doc/draft-zha-detnet-requirments/
Htmlized:       https://tools.ietf.org/html/draft-zha-detnet-requirments-00

Abstract:
   Deterministic Networking (DetNet) is focused on how to serve time
   critical flow with low data loss and bounded delay. Unlike
   contemporary solution which improves QoS such as TE, redundant
   bandwidth provisioning and dedicated channel reservation, DetNet
   provides more general approaches that use IP-based techniques and
   guarantee the worst-case latency of DetNet flows while allowing
   sharing among best-effort flows. For this purpose, DetNet may
   require upgraded or redefined data plane as well as control plane,
   since current networking cannot assure maximum end-to-end latency.
   This document describes some technical requirements on possible
   data plane, control plane and DetNet flow modeling that can help
   to clarify those capabilities DetNet should have.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: John Grant <[email-masked]>
Date: Tue, 22 Mar 2016 17:54:48 +0000

> Here is a requirements draft for your reading pleasure. The name may not be appropriated since the draft talks about some technical consideration on data plane, control plane and modeling. We take…

In the last paragraph of 5.1 you say the communication between network elements and the controller will add to latency. But the data packets won't go via the controller, so it will only affect the time to set the flow up, and in a large network it will probably be quicker to make the routing decision in one place and then send the setup information to all NEs simultaneously than for the NEs to set it up hop by hop.

However, I think distributed control is still needed so that small private networks can be truly plug-and-play.

John Grant
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com

---

From: zhayiyong <[email-masked]>
Date: Wed, 23 Mar 2016 01:15:44 +0000

Hi John,

Thank you for your comments. Please find my responses in-line.

Regards,
Yiyong
-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of John Grant
Sent: Wednesday, March 23, 2016 1:55 AM
To: [email-masked]
Subject: Re: [Detnet] FW: New Version Notification for draft-zha-detnet-requirments-00.txt

In the last paragraph of 5.1 you say the communication between network elements and the controller will add to latency. But the data packets won't go via the controller, so it will only affect the time to set the flow up, and in a large network it will probably be quicker to make the routing decision in one place and then send the setup information to all NEs simultaneously than for the NEs to set it up hop by hop.
[zyy] Sorry for the confusion here, of course the data packet will not go to controller if the switch contains a match rule. However, it is assumed that all time critical flows has been pre-configured via application layer. If there is a new flow comes in without a match rule, switch will send the packet to the controller requesting for an action to execute, which may be critical for real time service. 

[zyy] Agree.

John Grant

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

---

From: John Grant <[email-masked]>
Date: Wed, 23 Mar 2016 11:14:35 +0000

I don't think we can expect to be able to provide QoS guarantees such as defined latency to a flow that hasn't been set up (including writing match rules etc in all the switches through which it passes) by some kind of control-plane negotiation between the application and the network.

Applications that need low latency can typically tolerate quite long set-up times, e.g. a performer may need latency below 25 ms from microphone via mixing desk to headphones but will be happy if the system can set the connections up in less than a second.

John Grant

---

From: zhayiyong <[email-masked]>
Date: Thu, 24 Mar 2016 01:23:05 +0000

Hi John,

I agree with you on that some applications should expect pre-configuration for delay guarantee service. In some cases, such as sensor network, the sensor get the data and send it right away with a delay requirement. And there are tons of sensors so it is not easy to setup low latency paths for each on
I agree with you that we can focus on cases with pre-configuration first.  

Regards,
Yiyong

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of John Grant
Sent: Wednesday, March 23, 2016 7:15 PM
To: [email-masked]
Subject: Re: [Detnet] FW: New Version Notification for draft-zha-detnet-requirments-00.txt

John Grant

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Thu, 24 Mar 2016 04:40:09 +0000

Hi John,
Just to note that for some Pro Audio use cases a "long" setup time (like one second) for a stream may be acceptable, however in other use cases such as industrial it may be less acceptable, for example the case of bringing up a replacement device for one that has failed in a time-critical system such as a Utilities network. Not that there aren't ways to ensure a deterministic "hot swap", I'm just saying. 
Ethan.

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of zhayiyong
Sent: Wednesday, March 23, 2016 6:23 PM
To: John Grant; [email-masked]
Subject: Re: [Detnet] FW: New Version Notification for draft-zha-detnet-requirments-00.txt

Hi John,

I agree with you on that some applications should expect pre-configuration for delay guarantee service. In some cases, such as sensor network, the sensor get the data and send it right away with a delay requirement. And there are tons of sensors so it is not easy to setup low latency paths for each on I agree with you that we can focus on cases with pre-configuration first.  

Regards,
Yiyong

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of John Grant
Sent: Wednesday, March 23, 2016 7:15 PM
To: [email-masked]
Subject: Re: [Detnet] FW: New Version Notification for draft-zha-detnet-requirments-00.txt

John Grant

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 24 Mar 2016 09:31:59 +0000

Hello Ethan:

The requirements for Elimination and Replication should be such as to enable hot swap for a device that is giving signs of weakness  or has crashed, and apparently they are. Clearly there's a high demand of the existing protocols (PRP/HSR) in environments where continuous connectivity is critical enough to justify physical redundancy.

OTOH if a physical device is a single point of failure, and it is down, then I'm not sure one second makes a difference in the light of the whole replacement workflow.

Cheers,

Pascal

> From: detnet [mailto:[email-masked]] On Behalf Of Grossman,
> Ethan A.
> Sent: jeudi 24 mars 2016 05:40
> To: zhayiyong <[email-masked]>; John Grant <[email-masked]>;
> [email-masked]
> Just to note that for some Pro Audio use cases a "long" setup time (like one
> second) for a stream may be acceptable, however in other use cases such as
> industrial it may be less acceptable, for example the case of bringing up a
> replacement device for one that has failed in a time-critical system such as a
> Utilities network. Not that there aren't ways to ensure a deterministic "hot
> swap", I'm just saying.
> Ethan.
> 
> I agree with you on that some applications should expect pre-configuration
> for delay guarantee service. In some cases, such as sensor network, the
> sensor get the data and send it right away with a delay requirement. And
> there are tons of sensors so it is not easy to setup low latency paths for each
> on I agree with you that we can focus on cases with pre-configuration first.
> 
> Regards,
> Yiyong
> 
> I don't think we can expect to be able to provide QoS guarantees such as
> defined latency to a flow that hasn't been set up (including writing match
> rules etc in all the switches through which it passes) by some kind of control-
> plane negotiation between the application and the network.
> 
> Applications that need low latency can typically tolerate quite long set-up
> times, e.g. a performer may need latency below 25 ms from microphone via
> mixing desk to headphones but will be happy if the system can set the
> connections up in less than a second.
> 
> John Grant
> >> Here is a requirements draft for your reading pleasure. The name may not
> be appropriated since the draft talks about some technical consideration on
> data plane, control plane and modeling. We take this one as an input for
> discussion.
> >
> > In the last paragraph of 5.1 you say the communication between network
> elements and the controller will add to latency. But the data packets won't
> go via the controller, so it will only affect the time to set the flow up, and in
> a large network it will probably be quicker to make the routing decision in
> one place and then send the setup information to all NEs simultaneously
> than for the NEs to set it up hop by hop.
> > [zyy] Sorry for the confusion here, of course the data packet will not go to
> controller if the switch contains a match rule. However, it is assumed that all
> time critical flows has been pre-configured via application layer. If there is a
> new flow comes in without a match rule, switch will send the packet to the
> controller requesting for an action to execute, which may be critical for real
> time service.
> >

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Thu, 24 Mar 2016 22:16:39 +0000

Duly noted, thanks Pascal.
Ethan.

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
Sent: Thursday, March 24, 2016 2:32 AM
To: Grossman, Ethan A.; zhayiyong; John Grant; [email-masked]
Subject: RE: [Detnet] FW: New Version Notification for draft-zha-detnet-requirments-00.txt

Hello Ethan:

Cheers,

Pascal

> Subject: Re: [Detnet] FW: New Version Notification for 
> draft-zha-detnet- requirments-00.txt
> 
> Hi John,
> second) for a stream may be acceptable, however in other use cases 
> such as industrial it may be less acceptable, for example the case of 
> bringing up a replacement device for one that has failed in a 
> time-critical system such as a Utilities network. Not that there 
> aren't ways to ensure a deterministic "hot swap", I'm just saying.
> Ethan.
> 
> Subject: Re: [Detnet] FW: New Version Notification for 
> draft-zha-detnet- requirments-00.txt
> 
> Hi John,
> 
> I agree with you on that some applications should expect 
> pre-configuration for delay guarantee service. In some cases, such as 
> sensor network, the sensor get the data and send it right away with a 
> delay requirement. And there are tons of sensors so it is not easy to 
> setup low latency paths for each on I agree with you that we can focus on cases with pre-configuration first.
> 
> Regards,
> Yiyong
> 
> Subject: Re: [Detnet] FW: New Version Notification for 
> draft-zha-detnet- requirments-00.txt
> 
> I don't think we can expect to be able to provide QoS guarantees such 
> as defined latency to a flow that hasn't been set up (including 
> writing match rules etc in all the switches through which it passes) 
> by some kind of control- plane negotiation between the application and the network.
> 
> Applications that need low latency can typically tolerate quite long 
> set-up times, e.g. a performer may need latency below 25 ms from 
> microphone via mixing desk to headphones but will be happy if the 
> system can set the connections up in less than a second.
> 
> John Grant
> be appropriated since the draft talks about some technical 
> consideration on data plane, control plane and modeling. We take this 
> one as an input for discussion.
> >
> elements and the controller will add to latency. But the data packets 
> won't go via the controller, so it will only affect the time to set 
> the flow up, and in a large network it will probably be quicker to 
> make the routing decision in one place and then send the setup 
> information to all NEs simultaneously than for the NEs to set it up hop by hop.
> controller if the switch contains a match rule. However, it is assumed 
> that all time critical flows has been pre-configured via application 
> layer. If there is a new flow comes in without a match rule, switch 
> will send the packet to the controller requesting for an action to 
> execute, which may be critical for real time service.
> >
> > However, I think distributed control is still needed so that small 
> > private
> networks can be truly plug-and-play.
> > [zyy] Agree.
> >
> > John Grant