Subject: [Detnet] Distributed/Central Management (was] Draft DetNet Charter)

From: "Pat (Patricia) Thaler" <[email-masked]>
Date: Wed, 2 Sep 2015 22:52:01 +0000

Please limit discussion under the subject Draft DetNet Charter to comments about and support of the Charter.

Discussion on other topics is good and encouraged, but please use a subject line that reflects the topic.

Regards,
Pat

From: detnet [mailto:[email-masked]] On Behalf Of Norman Finn (nfinn)
Sent: Wednesday, September 02, 2015 3:42 PM
To: S.V.R.Anand; Prof. Diego Dujovne
Cc: [email-masked]
Subject: Re: [Detnet] Draft DetNet Charter

Anand, Diego, and others,

(I agree with Pascal — this is waaay beyond the charter discussion, but is interesting, nevertheless.)

I’ve convinced myself that a distributed algorithm, performed by the network elements, is certainly possible, but am undecided whether defining one should be a 1) very, very long-term goal that I won’t worry about, or 2) something to be avoided, entirely. :)

Basically, the needs in any network that is large enough to have outgrown the purely L2 solutions that are now available are too advanced to be met by the kinds of simplistic answers that a peer-to-peer control plane can provide.

It is easy to imagine all sorts of global constraints that you want the mass of reservations to meet, such as:

 A) Leaving sufficient best-effort bandwidth available on certain links or nodes.
 B) Avoiding certain links that may be prone to failure due to frequently-flexed cables.
 C) Meeting security requirements to not pass X’s data through Y’s portion of the network.
 D) Making sure that certain flows avoid sharing links, while other flows do share.
 E) Making return paths symmetrical or not.
 F) Moving active paths with more-easily met latency requirements to take a longer route, in order to squeeze in a new low-latency path.
 G) Balancing complex time-scheduled transmission requirements over a mesh network.
 H) Avoiding simultaneous transmissions on adjacent but separate physical wires to avoid simultaneous RF interference.
 I) I could go on for a long, long, long time.

All of the above could, in theory, be made the subject of an ISIS-like distributed algorithm, where all the network nodes run the same algorithm and thus come to the same conclusion.  I’d much rather spend my time on a standard that makes it possible to do the above in a godbox, and provides for a hierarchy (or at least, a confederation) of godboxes and backups.

— Norm

From: detnet <[email-masked]<mailto:[email-masked]>> on behalf of "S.V.R.Anand" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 2, 2015 at 09:28 AM
To: "Prof. Diego Dujovne" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Detnet] Draft DetNet Charter

Diego,

Yes, indeed. The distributed management helps for the reasons you stated.

I have a one concern though. If you imply that the distributed management is
performed by the network elements, then these need to have an up-to-date
knowledge about the global network usage, and the necessary logic that usually
runs on a dedicated central controller. Can we expect this functionality in
today's systems ?

Anand

On Wednesday 02 September 2015 08:28 PM, Prof. Diego Dujovne wrote:
> There is also the possibility of a distributed management, mainly to add

> redundancy and increase reliability of the system in case the centralized

> management is not available.

> Do you agree?

>                            Diego

> 2015-09-02 10:25 GMT-03:00 S.V.R.Anand <mailto:[email-masked]>
<[email-masked]><mailto:[email-masked]>:

>     Hi All,

>     Related to this ongoing discussion on flow management, I am wondering if there are application scenarios where we may have to tightly bound the delay in setting up a new application flow, during run-time, before data for that flow starts coming in.

>     If there are indeed use cases, this question can be mostly addressed by a central manager that is expected to have an up-to-date knowledge about the resource usage. But if the network state exhibits temporal behaviour, as in wireless, then we may have
to figure out ways of minimising the delay in terms of setting up route and bandwidth resources.

>     Am I making sense ?

>     Anand

>     On Tuesday 01 September 2015 10:15 PM, Rodney Cummings wrote:

>>     Hi Pat,

>>     > The text applies equally to management or the bandwidth consumer explicitly releasing bandwidth as well as to cases where automatic release occurs.

>>     I agree. That's what I meant when I said that management supports hard-state or soft-state. I am fine with the charter text as is.

>>     When I say hard-state, I mean explicit release. Management writes variables, but there is no periodic confirmation of resource use. This will be common in automotive, and in some smaller-scale industrial applications. I don't think we should limit these
applications to layer-2.

>>     When I say soft-state, I mean that the central manager uses a protocol to periodically confirm resource usage. This could be MSRP, RSVP, IS-IS, PCEP... whatever we decide to enhance. This will be common in larger-scale applications including factory
automation.

>>     We can also support technologies that do not require management at all. I was discussing management mainly in the context of scheduled traffic.

>>     Rodney

>>     From:        "Pat (Patricia) Thaler" <mailto:[email-masked]>
<[email-masked]><mailto:[email-masked]>

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

>>     Date:        08/31/2015 09:18 PM

>>     Subject:        Re: [Detnet] Draft DetNet Charter

>>     Sent by:        "detnet" <mailto:[email-masked]>
<[email-masked]><mailto:[email-masked]>

>>     Hi Rodney,

>>     The charter text says:

>>     "...and 2) release/reuse the resources when they are no more required..."

>>     which says nothing about automatic release of resources. When reservations are set up by management, management would also have a way to release the resource. The text applies equally to management or the bandwidth consumer explicitly releasing bandwidth
as well as to cases where automatic release occurs.

>>     It is more likely that an in car control path would be layer 2 and covered by the work IEEE 802.1 is doing.  The building monitoring and control use case is an example where Layer 3 with some of the configuration relatively static (security monitoring
systems, environmental control, etc.). Or control on a manufacturing line.

>>     Regards,

>>     Pat

>>     From: detnet [mailto:[email-masked]] On Behalf Of Rodney Cummings

>>     Sent: Monday, August 31, 2015 8:28 AM

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

>>     Subject: Re: [Detnet] Draft DetNet Charter

>>     Hello,

>>     I agree that we should address applications that need soft-state (i.e. automatic release of resources when no longer used), but I do not think that the DetNet work should prohibit applications from using hard-state.

>>     As a specific example, consider a network within a car that is used for cyber-physical control (e.g. engine, transmission). The devices for this application never change, and the network cabling and routing never changes, and therefore the DetNet traffic
is never expected to change. Traffic for other purposes (e.g. Internet browsing) may be desirable, but it is definitely not as critical. For this application, locking down the resources for DetNet traffic is desired.

>>     In the TSN work thus far, the mechanism for configuring 802.1Qbv schedules is management. The general assumption is that management of 802.1Qbv can be handled in either a hard-state or soft-state manner, depending on the application. If 802.1Qbv is used
in an IT network, I would expect soft-state to be used.

>>     The existing AVB standards in the field (802.1Qav and 802.1Qat, aka SRP) are entirely soft-state, with SRP using bandwidth for AVB traffic only when AVB packets exist, and SRP freeing all resources on timeout (soft-state). Nevertheless, in the amendment
to SRP (802.1Qcc), we are adding the capability to configure AVB resources using management, which will enable hard-state applications. Automotive applications of AVB are using a hard-state approach already.

>>     Rodney

>>     From:        Balázs Varga A <mailto:[email-masked]>
<[email-masked]><mailto:[email-masked]>

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

>>     Date:        08/31/2015 07:28 AM

>>     Subject:        Re: [Detnet] Draft DetNet Charter

>>     Sent by:        "detnet" <mailto:[email-masked]>
<[email-masked]><mailto:[email-masked]>

>>     Hi,

>>     I agree, release of unused resources is an important task to be solved by the WG.

>>     The situation with some TSN tools can be even worst than what you have described below.

>>     E.g. using 802.1Qbv Enhancements for Scheduled Traffic in some cases no other traffic (including best-effort) can use the reserved bandwidth.

>>     So if You have reserved all the bandwidth but all high priority flows are terminated no traffic can cross your link.

>>     Cheers

>>     Balazs

>>     From: detnet [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)

>>     Sent: Saturday, August 29, 2015 12:24 PM

>>     To: John Grant

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

>>     Subject: Re: [Detnet] Draft DetNet Charter

>>     Yes, It is Kind of Easy to reuse bandwidth outgoing the switch if there was no incoming packet; what's harder is to discover that the flow is terminated.

>>     This will impact the flow description and or the protocols (e.g. Associating a lifetime and a continuous renewal process to the registration)

>>     Point taken! I agree that this does not impact the charter, though.

>>     Cheers,

>>     Pascal

>>     Pascal

>>     Le 29 août 2015 à 12:11, John Grant <mailto:[email-masked]>
<[email-masked]><mailto:[email-masked]> a écrit :

>>     On 28 Aug 2015, at 23:15, Grossman, Ethan A. wrote:

>>     Hi Folks,

>>     I think the draft charter looks really good, and hits the right points. I have a question about this phrase:

>>     "...and 2) release/reuse the resources when they are no more required..."

>>     One of the concerns about AVB/TSN (and "reserved bandwidth" schemes in general) that I heard from our IT guys, in the context of a corporate network, was that "once users reserved bandwidth for the streams they wanted, when they were "done" they would
never get around to tearing the streams down, and so that bandwidth would remain unusable by others on the network".

>>     [snip]

>>     I suppose such "stale" reserved bandwidth would prevent others from reserving that bandwidth,

>>     Exactly -- I think that's what they're referring to; you could finish up with a link on which all the bandwidth is reserved but none is used, in which case 100% of the link is available for best-effort traffic but no new time-sensitive flows can use
it.

>>     There's always a problem that folks may reserve resources they aren't using, which could involve actual traffic as well as reservations, e.g. sending video to a screen when no-one's watching it.

>>     John Grant

>>     Nine Tiles, Cambridge, England

>>     +44 1223 862599 and +44 1223 511455

>>     http://www.ninetiles.com

>>     _______________________________________________

>>     detnet mailing list

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

>>     <https://www.ietf.org/mailman/listinfo/detnet_______________________________________________>
https://www.ietf.org/mailman/listinfo/detnet_______________________________________________

>>     detnet mailing list

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

>>     <https://www.ietf.org/mailman/listinfo/detnet_______________________________________________>
https://www.ietf.org/mailman/listinfo/detnet_______________________________________________

>>     detnet mailing list

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

>>     <https://www.ietf.org/mailman/listinfo/detnet>
https://www.ietf.org/mailman/listinfo/detnet

>>     --

>>     This message has been scanned for viruses and

>>     dangerous content by MailScanner, and is

>>     believed to be clean.

>>     _______________________________________________

>>     detnet mailing list

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

>>     <https://www.ietf.org/mailman/listinfo/detnet>
https://www.ietf.org/mailman/listinfo/detnet

>     --

>     This message has been scanned for viruses and

>     dangerous content by MailScanner, and is

>     believed to be clean.

>     _______________________________________________

>     detnet mailing list

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

>     <https://www.ietf.org/mailman/listinfo/detnet>
https://www.ietf.org/mailman/listinfo/detnet

> --

> DIEGO DUJOVNE

> Académico Escuela de Ingeniería en Informática y Telecomunicaciones

> Facultad de Ingeniería UDP

> www.ingenieria.udp.cl<http://www.ingenieria.udp.cl>

> (56 2) 676 8125

> --

> This message has been scanned for viruses and

> dangerous content by MailScanner, and is

> believed to be clean.

> _______________________________________________

> detnet mailing list

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

> <https://www.ietf.org/mailman/listinfo/detnet>
https://www.ietf.org/mailman/listinfo/detnet

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.