Re: [Detnet] Draft DetNet Charter

[Thomas Watteyne <[e-mail]>]

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 <
[e-mail]> 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 <[e-mail]>:
>
>> 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 <[e-mail]>
>> <[e-mail]>:
>> >
>> >     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" <[e-mail]>
>> <[e-mail]>
>> >>     To:        "[e-mail]" <[e-mail]>
>> <[e-mail]> <[e-mail]>, "[e-mail]"
>> <[e-mail]> <[e-mail]> <[e-mail]>,
>> >>     Date:        08/31/2015 09:18 PM
>> >>     Subject:        Re: [Detnet] Draft DetNet Charter
>> >>     Sent by:        "detnet" <[e-mail]>
>> <[e-mail]>
>> >>
>> >>
>> >>
>> >>     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:[e-mail]
>> <[e-mail]>] On Behalf Of Rodney Cummings
>> >>     Sent: Monday, August 31, 2015 8:28 AM
>> >>     To: [e-mail]
>> >>     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 <[e-mail]>
>> <[e-mail]>
>> >>     To:        "[e-mail]" <[e-mail]> <[e-mail]>
>> <[e-mail]>,
>> >>     Date:        08/31/2015 07:28 AM
>> >>     Subject:        Re: [Detnet] Draft DetNet Charter
>> >>     Sent by:        "detnet" <[e-mail]>
>> <[e-mail]>
>> >>
>> >>
>> >>
>> >>
>> >>     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:[e-mail]
>> <[e-mail]>] On Behalf Of Pascal Thubert (pthubert)
>> >>     Sent: Saturday, August 29, 2015 12:24 PM
>> >>     To: John Grant
>> >>     Cc: [e-mail]
>> >>     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 <[e-mail]>
>> <[e-mail]> 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
>> >>     [phone] and [phone]
>> >>     http://www.ninetiles.com
>> >>
>> >>     _______________________________________________
>> >>     detnet mailing list
>> >>     [e-mail]
>> >>
>> https://www.ietf.org/mailman/listinfo/detnet_______________________________________________
>> >>     detnet mailing list
>> >>     [e-mail]
>> >>
>> https://www.ietf.org/mailman/listinfo/detnet_______________________________________________
>> >>     detnet mailing list
>> >>     [e-mail]
>> >>     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
>> >>     [e-mail]
>> >>     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
>> >     [e-mail]
>> >     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
>> > (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
>> > [e-mail]
>> > 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
> (56 2) 676 8125
>
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet
>
>