Re: [Detnet] Draft DetNet Charter

Hello Pat:

Certainly this thread is going beyond charter discussion but as long as it's not on the way I see that as WG work starting up and I would encourage it.

On the side, my view of the OTF work is that it allows statistical mux'ed traffic over a deterministic MAC by placing ad-hoc one-hop reservations in a very adaptive fashion. This applies probably more to radios where everything must be scheduled at the MAC level in order to provide any guarantee to the deterministic traffic.

The OTF work depends a lot on the MAC so it makes sense that 6TiSCH continues its activities there.

Cheers,

Pascal

Le 2 sept. 2015 à 21:06, Pat (Patricia) Thaler <pthaler@broadcom.com<mailto:pthaler@broadcom.com>> a écrit :

This is details to work out in the Working Group. The charter doesn't need this detail level.

Sent from my iPhone

On Sep 2, 2015, at 10:52 AM, Thomas Watteyne <watteyne@eecs.berkeley.edu<mailto:watteyne@eecs.berkeley.edu>> wrote:

I strongly agree that a distributed approach in the low-power wireless networks will get you what you are looking for. At 6TiSCH, we work on technique "on The Fly" scheduling [1] which does just that.
Thomas

[1] https://tools.ietf.org/html/draft-dujovne-6tisch-on-the-fly-06

On Wed, Sep 2, 2015 at 7:47 PM, Prof. Diego Dujovne <diego.dujovne@mail.udp.cl<mailto:diego.dujovne@mail.udp.cl>> wrote:
Anand,
            I see your concern. I think this kind of functionality can be
achieved in today's systems as long as the (possibly incremental)
updates on network knowledge are shared between the redundant
controllers.
           In a second step, a distributed resource allocation
system (allowing every network element to negotiate resources)
is possible as a complement to a centralized approach.
           Furthermore, from my point of view, a fully distributed
resource allocation is feasible for small networks, where scalability
is not a problem.
            What do you think?
            Regards,

                                         Diego

2015-09-02 13:28 GMT-03:00 S.V.R.Anand <anand@ece.iisc.ernet.in<mailto:anand@ece.iisc.ernet.in>>:
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 <anand@ece.iisc.ernet.in><mailto:anand@ece.iisc.ernet.in>:
>
>     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" <pthaler@broadcom.com><mailto:pthaler@broadcom.com>
>>     To:        "rodney.cummings@ni.com"<mailto:rodney.cummings@ni.com> <rodney.cummings@ni.com><mailto:rodney.cummings@ni.com>, "detnet@ietf.org"<mailto:detnet@ietf.org> <detnet@ietf.org><mailto:detnet@ietf.org>,
>>     Date:        08/31/2015 09:18 PM
>>     Subject:        Re: [Detnet] Draft DetNet Charter
>>     Sent by:        "detnet" <detnet-bounces@ietf.org><mailto:detnet-bounces@ietf.org>
>>
>>
>>
>>     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:detnet-bounces@ietf.org] On Behalf Of Rodney Cummings
>>     Sent: Monday, August 31, 2015 8:28 AM
>>     To: detnet@ietf.org<mailto:detnet@ietf.org>
>>     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 <balazs.a.varga@ericsson.com><mailto:balazs.a.varga@ericsson.com>
>>     To:        "detnet@ietf.org"<mailto:detnet@ietf.org> <detnet@ietf.org><mailto:detnet@ietf.org>,
>>     Date:        08/31/2015 07:28 AM
>>     Subject:        Re: [Detnet] Draft DetNet Charter
>>     Sent by:        "detnet" <detnet-bounces@ietf.org><mailto:detnet-bounces@ietf.org>
>>
>>
>>
>>
>>     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
>>     Bala zs
>>
>>     From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
>>     Sent: Saturday, August 29, 2015 12:24 PM
>>     To: John Grant
>>     Cc: detnet@ietf.org<mailto:detnet@ietf.org>
>>     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 <j@ninetiles.com><mailto:j@ninetiles.com> 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<tel:%2B44%201223%20862599> and +44 1223 511455<tel:%2B44%201223%20511455>
>>     http://www.ninetiles.com
>>
>>     _______________________________________________
>>     detnet mailing list
>>     detnet@ietf.org<mailto:detnet@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/detnet_______________________________________________
>>     detnet mailing list
>>     detnet@ietf.org<mailto:detnet@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/detnet_______________________________________________
>>     detnet mailing list
>>     detnet@ietf.org<mailto:detnet@ietf.org>
>>     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
>>     detnet@ietf.org<mailto:detnet@ietf.org>
>>     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
>     detnet@ietf.org<mailto:detnet@ietf.org>
>     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
> detnet@ietf.org<mailto:detnet@ietf.org>
> 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.

--
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

_______________________________________________
detnet mailing list
detnet@ietf.org<mailto:detnet@ietf.org>
https://www.ietf.org/mailman/listinfo/detnet

_______________________________________________
detnet mailing list
detnet@ietf.org<mailto:detnet@ietf.org>
https://www.ietf.org/mailman/listinfo/detnet
_______________________________________________
detnet mailing list
detnet@ietf.org<mailto:detnet@ietf.org>
https://www.ietf.org/mailman/listinfo/detnet