Subject: [Detnet] DetNet - Migration path

From: "Grossman, Ethan A." <[email-masked]>
Date: Fri, 7 Oct 2016 17:42:16 +0000

Hi Folks,

I did a brief "DetNet Status" presentation to the AVnu Alliance Technical Working Group, which is an industry group that promotes AVB/TSN. The attendance at this particular meeting was mostly Pro Audio people, and their main line of questioning was "What is the plan for incrementally migrating users from where they are today to increasingly improved network performance, which would eventually culminate in "full DetNet"?"  Another way to put it might be "Can we leverage the work of DetNet to improve networking capabilities between now and when DetNet is implemented on most routers?"

As far as I know, we don't have a plan to roll out a "migration path" with intermediate performance levels, using today's protocols, perhaps with "minor" changes to support DetNet. We are designing an architecture and protocol extensions that will do the job, leveraging existing  protocols to the extent possible, but it is an end goal, not a roadmap.

Having said that, do we have any other more helpful reply to this line of questioning?

Thanks,
Ethan.

---

From: Rodney Cummings <[email-masked]>
Date: Fri, 7 Oct 2016 18:22:57 +0000

Great topic,

I'm not completely clear on what it would mean for a router to support DetNet, but let's assume it means that the router:
1. Uses one of the solutions from draft-dt-detnet-dp-alt to identify flows of DetNet data.
2. Uses queuing/shaping/scheduling techniques from 802.1Q to provide DetNet guarantees for that data (e.g. max latency).
3. Provides YANG management for #1 and #2.

All of this could be done today using vendor-specific YANG modules, with centralized network management software from that vendor. That's not ideal of course, but it is useful.

How would a user application (protocol from draft-ietf-detnet-use-cases) use this?

I would argue that the user applications should use the "API" specified in 802.1Qcc clause 46 (currently in draft). That API is agnostic of layer 2/3 details and the data-plane encoding. The user simply identifies the flows from the host perspective (e.g. UDP header fields), and requests a maximum latency. The API is used between the user's application and the centralized network management software. The API specifies YANG, so it can be implemented as a RESTful API or similar.

AVnu Alliance's goal is to certify conformance to standards (i.e. multiple vendors).

Can AVnu Alliance certify the vendor-specific router implementation? No
Can AVnu Alliance certify the 802.1Qcc API between the user application and the vendor-specific network manager? Yes
As time goes on and DetNet standards are published, can AVnu Alliance certification do deeper into the routers? Yes

That's one hypothetical intermediate plan.

Rodney

From: detnet [mailto:[email-masked]] On Behalf Of Grossman, Ethan A.
Sent: Friday, October 7, 2016 12:42 PM
To: [email-masked]
Subject: [Detnet] DetNet - Migration path

Hi Folks,

 
 
Thanks,
Ethan.

---

From: Norman Finn <[email-masked]>
Date: Fri, 7 Oct 2016 12:11:39 -0700

IMO, Ethan, the current work on P802.1Qcc and the brand-new PAR for Link Registration Protocol are exactly the sort of next steps that AVnu is looking for.

-- Norm

> On Oct 7, 2016, at 10:42, Grossman, Ethan A. <[email-masked]> wrote:
> 
> Hi Folks,
>  
> I did a brief “DetNet Status” presentation to the AVnu Alliance Technical Working Group, which is an industry group that promotes AVB/TSN. The attendance at this particular meeting was mostly Pro Audio people, and their main line of questioning was “What is the plan for incrementally migrating users from where they are today to increasingly improved network performance, which would eventually culminate in “full DetNet”?”  Another way to put it might be “Can we leverage the work of DetNet to improve networking capabilities between now and when DetNet is implemented on most routers?” 
>  
> As far as I know, we don’t have a plan to roll out a “migration path” with intermediate performance levels, using today’s protocols, perhaps with “minor” changes to support DetNet. We are designing an architecture and protocol extensions that will do the job, leveraging existing  protocols to the extent possible, but it is an end goal, not a roadmap.
>  
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Fri, 7 Oct 2016 20:21:08 +0000

Thanks Rodney. On a peripherally related note, one thing you mention below about 802.1Qcc is "the user ... requests a maximum latency". In another current DetNet discussion there is the distinction between the user requesting a specific latency (presumably implying a reply from the network saying whether it was available or not) vs only being able to query the network about its latency performance. I thought we were converging on the latter model, but now I'm not as clear. Am I missing something here? 
Thanks,
Ethan. 

-----Original Message-----
From: Rodney Cummings [mailto:[email-masked]] 
Sent: Friday, October 07, 2016 11:23 AM
To: Grossman, Ethan A.; [email-masked]
Subject: RE: DetNet - Migration path

Great topic,

Can AVnu Alliance certify the vendor-specific router implementation? No Can AVnu Alliance certify the 802.1Qcc API between the user application and the vendor-specific network manager? Yes As time goes on and DetNet standards are published, can AVnu Alliance certification do deeper into the routers? Yes

Rodney

Hi Folks,

 
 
Thanks,
Ethan.

---

From: Rodney Cummings <[email-masked]>
Date: Tue, 11 Oct 2016 12:54:02 +0000

Thanks Ethan,

The current draft of 802.1Qcc has both for each flow (stream):

- AccumulatedLatency: This is provided from network to user, and it represents the currently configured maximum latency.

- MaxLatency: This is provided from user to network as the maximum latency that the application requires. If AccumulatedLatency exceeds this value, the network reports failure (flow not configured).

The assumption was that the network configuration may need to adapt to changing physical hardware and/or the requirements of new flows, and therefore AccumulatedLatency isn't always stable.

Early drafts of 802.1Qcc had a MinLatency requirement (for low jitter), but that was removed due to concerns that it would require significant buffering. Application representatives (e.g. automotive, industrial) did not make strong arguments to keep MinLatency.

Rodney
> From: Grossman, Ethan A. [mailto:[email-masked]]
> Sent: Friday, October 7, 2016 3:21 PM
> To: Rodney Cummings <[email-masked]>; [email-masked]
> Thanks Rodney. On a peripherally related note, one thing you mention below
> about 802.1Qcc is "the user ... requests a maximum latency". In another
> current DetNet discussion there is the distinction between the user
> requesting a specific latency (presumably implying a reply from the
> network saying whether it was available or not) vs only being able to
> query the network about its latency performance. I thought we were
> converging on the latter model, but now I'm not as clear. Am I missing
> something here?
> Thanks,
> Ethan.
> 
> I'm not completely clear on what it would mean for a router to support
> DetNet, but let's assume it means that the router:
> 2. Uses queuing/shaping/scheduling techniques from 802.1Q to provide
> DetNet guarantees for that data (e.g. max latency).
> All of this could be done today using vendor-specific YANG modules, with
> centralized network management software from that vendor. That's not ideal
> of course, but it is useful.
> 
> I would argue that the user applications should use the "API" specified in
> 802.1Qcc clause 46 (currently in draft). That API is agnostic of layer 2/3
> details and the data-plane encoding. The user simply identifies the flows
> from the host perspective (e.g. UDP header fields), and requests a maximum
> latency. The API is used between the user's application and the
> centralized network management software. The API specifies YANG, so it can
> be implemented as a RESTful API or similar.
> 
> Can AVnu Alliance certify the 802.1Qcc API between the user application
> and the vendor-specific network manager? Yes As time goes on and DetNet
> standards are published, can AVnu Alliance certification do deeper into
> the routers? Yes
> 
> I did a brief "DetNet Status" presentation to the AVnu Alliance Technical
> Working Group, which is an industry group that promotes AVB/TSN. The
> attendance at this particular meeting was mostly Pro Audio people, and
> their main line of questioning was "What is the plan for incrementally
> migrating users from where they are today to increasingly improved network
> performance, which would eventually culminate in "full DetNet"?"  Another
> way to put it might be "Can we leverage the work of DetNet to improve
> networking capabilities between now and when DetNet is implemented on most
> routers?"
> 
> As far as I know, we don't have a plan to roll out a "migration path" with
> intermediate performance levels, using today's protocols, perhaps with
> "minor" changes to support DetNet. We are designing an architecture and
> protocol extensions that will do the job, leveraging existing  protocols
> to the extent possible, but it is an end goal, not a roadmap.
>

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Tue, 11 Oct 2016 22:10:33 +0000

Thanks Rodney. Since a DetNet network must provide bounded latency and jitter, once the network promises an AccumulatedLatency value to a flow, doesn't it have to maintain that value at least for the duration of the flow? We haven't discussed much about the consistency over time of such things as latency and jitter, but I assumed they would be within some given bound over time, right? Or is it an enduring property of the given network? Isn't that in effect a MinLatency value? 
Ethan.

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Rodney Cummings
Sent: Tuesday, October 11, 2016 5:54 AM
To: Grossman, Ethan A.; [email-masked]
Subject: Re: [Detnet] DetNet - Migration path

Thanks Ethan,

Rodney
> Thanks Rodney. On a peripherally related note, one thing you mention 
> below about 802.1Qcc is "the user ... requests a maximum latency". In 
> another current DetNet discussion there is the distinction between the 
> user requesting a specific latency (presumably implying a reply from 
> the network saying whether it was available or not) vs only being able 
> to query the network about its latency performance. I thought we were 
> All of this could be done today using vendor-specific YANG modules, 
> with centralized network management software from that vendor. That's 
> not ideal of course, but it is useful.
> 
> I would argue that the user applications should use the "API" 
> specified in 802.1Qcc clause 46 (currently in draft). That API is 
> agnostic of layer 2/3 details and the data-plane encoding. The user 
> simply identifies the flows from the host perspective (e.g. UDP header 
> fields), and requests a maximum latency. The API is used between the 
> user's application and the centralized network management software. 
> The API specifies YANG, so it can be implemented as a RESTful API or similar.
> 
> Can AVnu Alliance certify the vendor-specific router implementation? 
> No Can AVnu Alliance certify the 802.1Qcc API between the user 
> application and the vendor-specific network manager? Yes As time goes 
> on and DetNet standards are published, can AVnu Alliance certification 
> do deeper into the routers? Yes
> 
> I did a brief "DetNet Status" presentation to the AVnu Alliance 
> Technical Working Group, which is an industry group that promotes 
> AVB/TSN. The attendance at this particular meeting was mostly Pro 
> Audio people, and their main line of questioning was "What is the plan 
> for incrementally migrating users from where they are today to 
> increasingly improved network performance, which would eventually 
> culminate in "full DetNet"?"  Another way to put it might be "Can we 
> leverage the work of DetNet to improve networking capabilities between 
> now and when DetNet is implemented on most routers?"
> 
> As far as I know, we don't have a plan to roll out a "migration path" 
> with intermediate performance levels, using today's protocols, perhaps 
> with "minor" changes to support DetNet. We are designing an 
> architecture and protocol extensions that will do the job, leveraging 
> existing  protocols to the extent possible, but it is an end goal, not a roadmap.
>

---

From: Norman Finn <[email-masked]>
Date: Tue, 11 Oct 2016 17:02:02 -0700

That is, I believe, the current status of 802.1Qat. Going forward, some of us would prefer AccumulatedLatency to be advisory, and it would change if the network must change it, but never to exceed MaxLatency.

Rodney may have something to add to that about .1Qcc.

-- Norm

> On Oct 11, 2016, at 15:10, Grossman, Ethan A. <[email-masked]> wrote:
>

---

From: Craig Gunther <[email-masked]>
Date: Wed, 12 Oct 2016 00:44:11 +0000 (UTC)

Ethan,
You have two options here. 
Option 1: If you specify a MaxLatency (newly added in Qcc) then the network is free to reroute your stream as needed in order to make room for other streams that might be competing for bandwidth on a particular link, as long as the new path's latency does not exceed the MaxLatency.  See slides 3,4,5 of this presentation for a potential reason why you might want to do this: http://www.ieee802.org/1/files/public/docs2014/cc-cgunther-acceptable-latency-0314-v01.pdf. Please note that the presentation refers to AcceptableLatency, which has been named MaxLatency in Qcc.
Option 2: If you do not specify a MaxLatency then the AccumulatedLatency works as it always has; which is to not allow the AccumulatedLatency to exceed the reported value when the reservation was first created.
- Craig

      From: "Grossman, Ethan A." <[email-masked]>
 To: Rodney Cummings <[email-masked]>; "[email-masked]" <[email-masked]> 
 Sent: Tuesday, October 11, 2016 4:10 PM
 Subject: Re: [Detnet] DetNet - Migration path

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Rodney Cummings
Sent: Tuesday, October 11, 2016 5:54 AM
To: Grossman, Ethan A.; [email-masked]
Subject: Re: [Detnet] DetNet - Migration path

Thanks Ethan,

Rodney

---

From: Rodney Cummings <[email-masked]>
Date: Wed, 12 Oct 2016 12:25:25 +0000

No problem Ethan,

In 802.1Qcc, MaxLatency is the bounded latency over time. It might be uncommon for AccumulatedLatency to increase while the flow is in use, but the assumption is that it is possible.

> Sent: Tuesday, October 11, 2016 5:11 PM
> Thanks Rodney. Since a DetNet network must provide bounded latency and
> jitter, once the network promises an AccumulatedLatency value to a flow,
> doesn't it have to maintain that value at least for the duration of the
> flow? We haven't discussed much about the consistency over time of such
> things as latency and jitter, but I assumed they would be within some
> given bound over time, right? Or is it an enduring property of the given
> network? Isn't that in effect a MinLatency value?
> Ethan.
> 
> - AccumulatedLatency: This is provided from network to user, and it
> represents the currently configured maximum latency.
> 
> - MaxLatency: This is provided from user to network as the maximum latency
> that the application requires. If AccumulatedLatency exceeds this value,
> the network reports failure (flow not configured).
> 
> The assumption was that the network configuration may need to adapt to
> changing physical hardware and/or the requirements of new flows, and
> therefore AccumulatedLatency isn't always stable.
> 
> Early drafts of 802.1Qcc had a MinLatency requirement (for low jitter),
> but that was removed due to concerns that it would require significant
> buffering. Application representatives (e.g. automotive, industrial) did
> not make strong arguments to keep MinLatency.
> 
> Rodney