Subject: Re: [Detnet] Draft DetNet Charter

From: Rodney Cummings <[email-masked]>
Date: Tue, 1 Sep 2015 11:45:11 -0500

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" <[email-masked]>
To:     "[email-masked]" <[email-masked]>, 
"[email-masked]" <[email-masked]>, 
Date:   08/31/2015 09:18 PM
Subject:        Re: [Detnet] Draft DetNet Charter
Sent by:        "detnet" <[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]
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 <[email-masked]> 
To:        "[email-masked]" <[email-masked]>, 
Date:        08/31/2015 07:28 AM 
Subject:        Re: [Detnet] Draft DetNet Charter 
Sent by:        "detnet" <[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 
Bala’zs 
  
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]
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 <[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]
https://www.ietf.org/mailman/listinfo/detnet
_______________________________________________
detnet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/detnet
_______________________________________________
detnet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/detnet

---

From: "S.V.R.Anand" <[email-masked]>
Date: Wed, 02 Sep 2015 18:55:36 +0530

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:
> explicitly releasing bandwidth as well as to cases where automatic 
> release occurs.
>
> 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
>
>
>
> ------------------------------------------------------------------------
>
>
>
> Hi Rodney,
>
> The charter text says:
> 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]*
> Subject:* Re: [Detnet] Draft DetNet Charter
>
> Hello,
>
> 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 
> 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 <[email-masked] 
> <mailto:[email-masked]>_>
> To: "[email-masked] <mailto:[email-masked]>_" <[email-masked] 
> <mailto:[email-masked]>_>,
> Sent by: "detnet" <[email-masked] 
> <mailto:[email-masked]>_>
> ------------------------------------------------------------------------
>
>
>
>
> Hi,
>
> I agree, release of unused resources is an important task to be solved 
> by the WG.
>
> 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:[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.
>
> Le 29 août 2015 à 12:11, John Grant <[email-masked] 
> <mailto:[email-masked]>_> a écrit :
>
> I think the draft charter looks really good, and hits the right 
> points. I have a question about this phrase:
>
> 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]
>
>
> 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.
>
> 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
> +44 1223 862599 and +44 1223 511455_
> __http://www.ninetiles.com_ <http://www.ninetiles.com/>
>
> detnet mailing list_
> [email-masked] <mailto:[email-masked]>__
> ___https://www.ietf.org/mailman/listinfo/detnet_________________________________________________
> detnet mailing list_
> [email-masked] <mailto:[email-masked]>__
> ___https://www.ietf.org/mailman/listinfo/detnet_________________________________________________
> detnet mailing list
> [email-masked]
> __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.
>
>
> _

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Wed, 2 Sep 2015 11:58:13 -0300

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 <[email-masked]>:

> 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
>
>
> 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.
>
> <[email-masked]>
> To:        "[email-masked]" <[email-masked]>
> <[email-masked]> <[email-masked]>, "[email-masked]"
> <[email-masked]> <[email-masked]> <[email-masked]>,
> <[email-masked]>
> ------------------------------
>
>
>
> Hi Rodney,
>
> The charter text says:
> *From:* detnet [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Rodney Cummings
> * Sent:* Monday, August 31, 2015 8:28 AM
> * To:* [email-masked]
> * Subject:* Re: [Detnet] Draft DetNet Charter
>
> Hello,
>
> 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
> 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 <[email-masked]*
> <[email-masked]>
> *> To:        "[email-masked]* <[email-masked]>*" <[email-masked]*
> <[email-masked]>
>
>
> *>, Date:        08/31/2015 07:28 AM Subject:        Re: [Detnet] Draft
> DetNet Charter Sent by:        "detnet" <[email-masked]*
> <[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 Bala’zs   From: detnet [*
> *mailto:[email-masked]* <[email-masked]>
>
>
> *] On Behalf Of Pascal Thubert (pthubert) Sent: Saturday, August 29, 2015
> 12:24 PM To: John Grant Cc: [email-masked]* <[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 <[email-masked]* <[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 <%2B44%201223%20862599> and +44 1223 511455 <%2B44%201223%20511455>
> <http://www.ninetiles.com/>*
>
>
>
> *http://www.ninetiles.com <http://www.ninetiles.com>
> _______________________________________________ detnet mailing list *
> [email-masked]* <[email-masked]>
> *https://www.ietf.org/mailman/listinfo/detnet*
> <https://www.ietf.org/mailman/listinfo/detnet>
>
> *_______________________________________________ detnet mailing list *
> [email-masked]* <[email-masked]>
> *https://www.ietf.org/mailman/listinfo/detnet*
> <https://www.ietf.org/mailman/listinfo/detnet>
>
>
> *_______________________________________________ detnet mailing list
> [email-masked] <[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.
> _______________________________________________ detnet mailing list
> [email-masked] <[email-masked]>
> <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

---

From: "S.V.R.Anand" <[email-masked]>
Date: Wed, 02 Sep 2015 21:58:02 +0530

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:
 >     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.
 >>     > 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.
 >>     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.
 >>     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 
 >>
 >>     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.
 >>     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)
 >>     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)
points. I have a question about this phrase:
 >>     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 
 >>
 >>     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.
 >>     +44 1223 862599 and +44 1223 511455
https://www.ietf.org/mailman/listinfo/detnet_______________________________________________
 >>     [email-masked]
https://www.ietf.org/mailman/listinfo/detnet_______________________________________________

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Wed, 2 Sep 2015 14:47:53 -0300

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 <[email-masked]>:

> > 2015-09-02 10:25 GMT-03:00 S.V.R.Anand <[email-masked]>
> <[email-masked]>:
> >
> >     Hi All,
> >
> 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
> >
> >
> protocol to periodically confirm resource usage. This could be MSRP, RSVP,
> all. I was discussing management mainly in the context of scheduled traffic.
> >>
> >>     Rodney
> >>
> >>
> >>
> 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
> 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]
> <[email-masked]>] On Behalf Of Rodney Cummings
> for cyber-physical control (e.g. engine, transmission). The devices for
> this application never change, and the network cabling and routing never
> depending on the application. If 802.1Qbv is used in an IT network, I would
> expect soft-state to be used.
> >>
> SRP) are entirely soft-state, with SRP using bandwidth for AVB traffic only
> >>     To:        "[email-masked]" <[email-masked]> <[email-masked]>
> <[email-masked]>,
> >>     The situation with some TSN tools can be even worst than what you
> have described below.
> >>     Bala zs
> >>     From: detnet [mailto:[email-masked]
> <[email-masked]>] On Behalf Of Pascal Thubert (pthubert)
> there was no incoming packet; what's harder is to discover that the flow is
> terminated.
> >>
> >>     Le 29 août 2015 à 12:11, John Grant <[email-masked]>
> <[email-masked]> a écrit :
> >>
> >>     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
> but no new time-sensitive flows can use it.
> >>
> aren't using, which could involve actual traffic as well as reservations,

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 2 Sep 2015 19:51:55 +0200

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 <
[email-masked]> wrote:

>> temporal behaviour, as in wireless, then we may have to figure out ways of
>> aka SRP) are entirely soft-state, with SRP using bandwidth for AVB traffic
>> 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]
>> >>
>> >>

---

From: "S.V.R.Anand" <[email-masked]>
Date: Thu, 03 Sep 2015 00:29:43 +0530

Diego,

Thanks for the inputs! Surely, having redundant controllers certainly help.

Just to bring back to what I expressed in my mail, it has got to do with the
delay incurred in setting up an end-to-end reservation for a flow that 
requires
strict performance guarantees as demanded by a Detnet application, 
before the
application data is sent. Depending on how deep the network end points are
inside the network, and the nature of QoS request, the setup delay involves
creating/selecting a path(s) and installing bandwidth (re)allocation 
along the
way. I wouldn't like to transmit my data unless I really know the network is
aware of my demands and meet them ! I am only wondering if this initial 
setup
delay really matters to Detnet applications ? If so, can we really 
realistically bound
them to any delay that is required by such an application.

Anand

On Wednesday 02 September 2015 11:17 PM, Prof. Diego Dujovne wrote:
 >     knowledge about the global network usage, and the necessary logic 
that usually
 >     >>
 >     >>     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.
 >     >>     To:        "[email-masked]" 
<[email-masked]>, "[email-masked]" <[email-masked]>,
 >     >>     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.
 >     >>     From: detnet [mailto:[email-masked]] On Behalf Of 
Rodney Cummings
 >     >>     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.
 >     >>     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.
 >     >>     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)
 >     >>     I think the draft charter looks really good, and hits the 
right points. I have a question about this phrase:
 >     >>     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.

---

From: "Pat (Patricia) Thaler" <[email-masked]>
Date: Wed, 2 Sep 2015 19:05:59 +0000

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 <[email-masked]<mailto:[email-masked]>> 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

On Wed, Sep 2, 2015 at 7:47 PM, Prof. Diego Dujovne <[email-masked]<mailto:[email-masked]>> wrote:
Anand,

                                         Diego

2015-09-02 13:28 GMT-03:00 S.V.R.Anand <[email-masked]<mailto:[email-masked]>>:
Diego,

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:
> 2015-09-02 10:25 GMT-03:00 S.V.R.Anand <[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
>
>
>>     > 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" <[email-masked]><mailto:[email-masked]>
>>     To:        "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>,
>>     Sent by:        "detnet" <[email-masked]><mailto:[email-masked]>
>>
>>
>>
>>     Hi Rodney,
>>
>>     The charter text says:
>>     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
>>
>>     To: [email-masked]<mailto:[email-masked]>
>>     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 <[email-masked]><mailto:[email-masked]>
>>     To:        "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>,
>>     Sent by:        "detnet" <[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
>>     Bala zs
>>
>>     From: detnet [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
>>     Cc: [email-masked]<mailto:[email-masked]>
>>     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)
>>
>>     Le 29 août 2015 à 12:11, John Grant <[email-masked]><mailto:[email-masked]> a écrit :
>>
>>     I think the draft charter looks really good, and hits the right points. I have a question about this phrase:
>>
>>     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
>>     +44 1223 862599<tel:%2B44%201223%20862599> and +44 1223 511455<tel:%2B44%201223%20511455>
>>     http://www.ninetiles.com
>>
>>     [email-masked]<mailto:[email-masked]>
>>     [email-masked]<mailto:[email-masked]>
>>     [email-masked]<mailto:[email-masked]>
>>     [email-masked]<mailto:[email-masked]>
>     [email-masked]<mailto:[email-masked]>
> www.ingenieria.udp.cl<http://www.ingenieria.udp.cl>
> (56 2) 676 8125
>
> --
> [email-masked]<mailto:[email-masked]>

--
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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/detnet

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 2 Sep 2015 19:31:07 +0000

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 <[email-masked]<mailto:[email-masked]>> a écrit :

Sent from my iPhone

                                         Diego

Anand

---

From: Lou Berger <[email-masked]>
Date: Wed, 2 Sep 2015 16:01:12 -0400

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.
>
>> On Sep 2, 2015, at 10:52 AM, Thomas Watteyne
>> <[email-masked] <mailto:[email-masked]>> 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
>>>
>>> On Wed, Sep 2, 2015 at 7:47 PM, Prof. Diego Dujovne
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>     Anand,
>>>         > 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
>>>         <[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" <[email-masked]>
>>>         <mailto:[email-masked]> >>     To:       
>>>         "[email-masked]" <mailto:[email-masked]>
>>>         <[email-masked]> <mailto:[email-masked]>,
>>>         "[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"
>>>         <[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. >> >>    
>>>         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]> >>     To:       
>>>         "[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"
>>>         <[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 >>     Bala zs >>      >>    
>>>         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 <[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..." >>      >>    
>>>         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 >>     [email-masked]
>>>         <mailto:[email-masked]> >>    
>>>         >>     detnet mailing list >>     [email-masked]
>>>         <mailto:[email-masked]> >>    
>>>         >>     detnet mailing list >>     [email-masked]
>>>         <mailto:[email-masked]> >>    
>>>         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 > > >     --
>>>         >     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 > > > > >
>>>         -- > 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]> >
>>>     www.ingenieria.udp.cl <http://www.ingenieria.udp.cl>
>>>     (56 2) 676 8125
>>>
>>>     [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Wed, 2 Sep 2015 22:41:54 +0000

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,

Anand

---

From: "Pat (Patricia) Thaler" <[email-masked]>
Date: Thu, 3 Sep 2015 00:23:57 +0000

Thank you Lou. That is what I meant. I was replying on my phone while waiting for a dental cleaning so I kept it short.

Pat

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, September 02, 2015 1:01 PM
To: Pascal Thubert (pthubert)
Cc: Pat (Patricia) Thaler; Thomas Watteyne; [email-masked]; S.V.R.Anand; Prof. Diego Dujovne
Subject: Discussing WG topics (Was Re: [Detnet] Draft DetNet Charter)

Pascal,

Lou