[Detnet] Discussing WG topics (Was Re: Draft DetNet Charter)

[Lou Berger <[e-mail]>]

Pascal,
    keeping the discussion(s) going is great.  Just change the subject
line so that everyone knows that the thread is no longer
charter-impacting.  Picking an appropriate subject line will also help
identify different topics of future discussion without having to reread
through one really big thread...

So, again please do keep the discussion going -- just change the subject
line to something topic-specific.

Lou


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