Re: [Detnet] DetNet - Migration path

[nfinn <[e-mail]>]

Patrick,

You can build a real-time network baed on average latency and a statistical distribution of variation in latency.  I will claim that that is not a target application for DetNet.  The reason is that requires a test the system, tweak the parameters, measure … cycle to get it right.  Once right, you must not touch anything.  That can be done, today, with no help from TSN or DetNet, although some features of TSN (e.g. transmission preemption) may make life easier.

IMO, the target for DetNet is applications that use synchronized time.  They have to 1) know the MaxLatency value, so they know the deadline for transmitting action orders in time to be received before the action is to be performed; and 2) allocate enough buffer space at the receiver to accommodate the difference between MaxLatency and MinLatency.  Those two items are required to achieve real-time operations with 0 congestion loss no matter what the actual latency distribution looks like, and if those two items are done, then the actual distribution does not matter at all.  Average latency means nothing.  Variations from the averages mean nothing.  Max,Latency, and perhaps MinLatency, carry all the information that needs to be specified.

I’m not saying that one model is right or wrong; only that I’m not trying to solve all the world’s problems, or even all the world’s real-time problems.  I think that it would be best for DetNet to concentrate on the Min?Max problem, and leave the average/distribution problem to another effort.

— Norm

> On Oct 12, 2016, at 9:12 AM, Patrick Wetterwald (pwetterw) <[e-mail]> wrote:
> 
> Dear all,
> 
> I’m trying to catch up with the different mails exchanged in the last 15 days or so and I may have missed some information.
> 
> My big trouble is on the terminology. My guess is that we will have to converge to a single one and probably align the different WG documents (including use case) with this terminology.
> So terms like AccumulatedLatency, minlatency, maxlatency should be clearly defined within Detnet if we choose to use them.
> 
> The second aspect is that I see some diverging points of view if you are talking about Audio/video or Electrical/utility field or other use cases.
> Some examples: In Electrical and probably industrial use cases, we usually try to express delay, jitter related to the communication network and treat the overall time budget at a different stage.  
> Independently from the delay, the jitter and symmetry are really important as it could make a control loop or teleprotection to become unstable or diverge. 	
> 
> My 2 cents,
> 
> Patrick
> 
> 
> 
> On 12/10/2016, 14:25, "detnet on behalf of Rodney Cummings" <[e-mail] on behalf of [e-mail]> wrote:
> 
>    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.
> 
>> -----Original Message-----
>> From: Grossman, Ethan A. [mailto:[e-mail]]
>> Sent: Tuesday, October 11, 2016 5:11 PM
>> To: Rodney Cummings <[e-mail]>; [e-mail]
>> Subject: RE: DetNet - Migration path
>> 
>> 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:[e-mail]] On Behalf Of Rodney Cummings
>> Sent: Tuesday, October 11, 2016 5:54 AM
>> To: Grossman, Ethan A.; [e-mail]
>> Subject: Re: [Detnet] DetNet - Migration path
>> 
>> 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
>>> -----Original Message-----
>>> From: Grossman, Ethan A. [mailto:[e-mail]]
>>> Sent: Friday, October 7, 2016 3:21 PM
>>> To: Rodney Cummings <[e-mail]>; [e-mail]
>>> Subject: RE: DetNet - Migration path
>>> 
>>> 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:[e-mail]]
>>> Sent: Friday, October 07, 2016 11:23 AM
>>> To: Grossman, Ethan A.; [e-mail]
>>> Subject: RE: DetNet - Migration path
>>> 
>>> 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:[e-mail]] On Behalf Of Grossman,
>>> Ethan A.
>>> Sent: Friday, October 7, 2016 12:42 PM
>>> To: [e-mail]
>>> Subject: [Detnet] DetNet - Migration path
>>> 
>>> 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.
>>> 
>> 
>> _______________________________________________
>> detnet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/detnet
> 
>    _______________________________________________
>    detnet mailing list
>    [e-mail]
>    https://www.ietf.org/mailman/listinfo/detnet
> 
> 
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet