Subject: [Detnet] Draft DetNet Charter

From: "Grossman, Ethan A." <[email-masked]>
Date: Fri, 28 Aug 2015 22:15:44 +0000

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

My understanding is that reserved bandwidth with AVB/TSN is only used when traffic is actually flowing on the stream, leaving the bandwidth available for best effort traffic. It seems to me that to head off this objection, this point could be somehow communicated in this phrase, unless in DETNET that is not the case; for example if the network reserves channels for TSN traffic that are "permanently" allocated, and traffic from various streams is directed over those channels, then the two reservations are "decoupled" and the available reseerved bandwidth is limited only in the aggregate.

But going back to the LAN case, I suppose such "stale" reserved bandwidth would prevent others from reserving that bandwidth, so there might be some element of validity in the stated concern? Do we have to deal with that issue, and if so can we somehow include our intent in the charter? Or maybe this is too low a level of detail?

Another note on the quote above: if we keep this phrase, then grammatically it should read "...no longer required..." (not "no more required").

Best,
Ethan.

Ethan Grossman
Dolby Laboratories

---

From: Lou Berger <[email-masked]>
Date: Fri, 28 Aug 2015 18:41:15 -0400

Ethan,

I put the correction into the wiki.

I personally  think the other points you raise are good ones for the WG to 
discuss...

Thanks,
Lou

On August 28, 2015 6:16:16 PM "Grossman, Ethan A." <[email-masked]> wrote:

> 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".
>
> My understanding is that reserved bandwidth with AVB/TSN is only used when 
> traffic is actually flowing on the stream, leaving the bandwidth available 
> for best effort traffic. It seems to me that to head off this objection, 
> this point could be somehow communicated in this phrase, unless in DETNET 
> that is not the case; for example if the network reserves channels for TSN 
> traffic that are "permanently" allocated, and traffic from various streams 
> is directed over those channels, then the two reservations are "decoupled" 
> and the available reseerved bandwidth is limited only in the aggregate.
>
> But going back to the LAN case, I suppose such "stale" reserved bandwidth 
> would prevent others from reserving that bandwidth, so there might be some 
> element of validity in the stated concern? Do we have to deal with that 
> issue, and if so can we somehow include our intent in the charter? Or maybe 
> this is too low a level of detail?
>
> Another note on the quote above: if we keep this phrase, then grammatically 
> it should read "...no longer required..." (not "no more required").
>
> Best,
> Ethan.
>
> Ethan Grossman
> Dolby Laboratories
>
>
>
>
> ----------
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet
>

---

From: John Grant <[email-masked]>
Date: Sat, 29 Aug 2015 11:11:38 +0100

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

[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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 29 Aug 2015 10:23:56 +0000

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 :

Hi Folks,

[snip]

John Grant

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

---

From: Balázs Varga A <[email-masked]>
Date: Mon, 31 Aug 2015 12:28:19 +0000

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

Cheers,

Pascal

Pascal

Hi Folks,

[snip]

John Grant

---

From: Rodney Cummings <[email-masked]>
Date: Mon, 31 Aug 2015 10:27:55 -0500

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)

Cheers,
 
Pascal

Pascal

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

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

 
[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

---

From: "Pat (Patricia) Thaler" <[email-masked]>
Date: Mon, 31 Aug 2015 17:52:53 +0000

Release of unused bandwidth is important.

As far as TSN, currently the reservations use MSRP or MMRP (802.1 reservation protocols) which require periodic refreshes to keep the reservation alive. A current project 802.1Qcc is increasing the time out because the traffic from the protocol becomes excessive in a large subnet.

Whether the bandwidth is reusable by other traffic when the reserved bandwidth isn't used depends on which 802.1 protocol is being used.  If it is just credit-based shaper and strict priority that is being used to ensure the bandwidth, then other traffic can use the bandwidth. This is the protocol defined by the original AVB work and it provides for limiting latency and jitter.

But for cases where tighter latency control is required (e.g. control loops for automotive and industrial), the enhancements for scheduled traffic gates off transmission from other traffic classes so that the scheduled traffic can be sent exactly on schedule.

Even in the first case, terminating reservations for flows that had finished would be important for keeping a build-up of stale context in the routing/switching devices and for freeing the bandwidth for new reservations.

Regards,
Pat

From: detnet [mailto:[email-masked]] On Behalf Of Balázs Varga A
Sent: Monday, August 31, 2015 5:28 AM
To: [email-masked]
Subject: Re: [Detnet] Draft DetNet Charter

Hi,

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

Cheers,

Pascal

Pascal

Hi Folks,

[snip]

John Grant

---

From: "Pat (Patricia) Thaler" <[email-masked]>
Date: Tue, 1 Sep 2015 02:18:00 +0000

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

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

Cheers,

Pascal

Pascal

Hi Folks,

[snip]

John Grant
Nine Tiles, Cambridge, England
+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