Subject: Re: [Detnet] Draft charter discussion

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

Dear all,
            I think it is a matter of ranges which can be defined depending
on the type of environment and application, from what was presented
as an example at the BOF. What is a common point among them is
that IP as it is today, cannot solve the problem alone, but with resource
reservation, to comply with the different requirements. I agree with
Pascal on this point.
           Regards,

                                  Diego Dujovne

2015-08-31 12:22 GMT-03:00 Balázs Varga A <[email-masked]>:

> Hi Pascal,
>
> The comment on delay was not against any other parameters, just to
> highlight that "low delay" can mean even micro-sec requirements.
> I like your formulation " beyond the traditional expectations of IP
> protocols " (it is valid for other parameters as well like loss, jitter,
> etc.).
>
> Cheers
> Bala'zs
>
> -----Original Message-----
> From: Pascal Thubert (pthubert) [mailto:[email-masked]]
> Sent: Monday, August 31, 2015 3:54 PM
> To: Balázs Varga A; [email-masked]
> Subject: RE: [Detnet] Draft charter discussion
>
> Hello Bala'zs
>
> ... But then, some do not need to, and for some others, the critically is
> a time sync in usecs, a low jitter, or a guarantee of no more than 3 losses
> in a row. I'm afraid that exhibiting one property may make it appear like
> more important than another. I find the charter balanced, but then, maybe
> we could use the word "extreme" or some equivalent to reflect that " paths
> can provide bounded latency, loss and packet delay variation (jitter)" in
> ways that are beyond the traditional expectations of IP protocols.
>
> What do you think?
>
> Pascal
>
> > -----Original Message-----
> > From: detnet [mailto:[email-masked]] On Behalf Of Balázs
> > Varga A
> > Sent: lundi 31 août 2015 14:26
> > To: [email-masked]
> > Subject: Re: [Detnet] Draft charter discussion
> >
> > Hi,
> >
> > I would argue for explicitly highlighting sub-millisecond requirement
> > as many current protocols do not deal with such a timescale.
> >
> > Cheers
> > Bala'zs
> >
> > -----Original Message-----
> > From: detnet [mailto:[email-masked]] On Behalf Of Lou Berger
> > Sent: Friday, August 28, 2015 2:26 PM
> > To: [email-masked]; Janos Farkas
> > Subject: Re: [Detnet] Draft charter discussion
> >
> > János, (All)
> >
> > I've updated the wiki based on your comments, take a look.  See below
> > for specific response/open points.
> >
> > On 8/27/2015 6:22 PM, Lou Berger wrote:
> > > János,
> >
> > >  snips
> >
> > >> 2nd paragraph:
> > >> - I think it is quite important that we are often going below
> > >> milliseconds. I'd extend "controlled latency" with "controlled low
> > >> latency (even sub-milliseconds)" or sg like that.
> > While I don't disagree with the technical point, and I think it's
> > particularly important WRT PDV/jitter, I'm not sure this level of
> > detail really belongs in the charter.
> >
> > What do others think?
> >
> >
> > _______________________________________________
> > detnet mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/detnet
>
> _______________________________________________
> detnet mailing list
> [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: Lou Berger <[email-masked]>
Date: Wed, 2 Sep 2015 15:56:59 -0400

I've tried to capture discussed (and agreed upon) changes to date at:

http://trac.tools.ietf.org/bof/trac/wiki/DetNetDraftCharter

Also included are some nit language changes triggered from IESG comments.

Lou

PS  It's really great to see al the discussion on topics for the WG, but
please change the subject line -- and reserve it for discussions that
may impact the charter text. - Thanks

On 8/26/2015 2:41 PM, Lou Berger wrote:
> So a few of us have been having an offline discussion to get the ball
> rolling on a draft WG charter discussion.  Here's what we have so far. 
> I think we all recognize it isn't perfect, but it's a starting point for
> the discussion.
>
> Please comment / provide specific proposals for modification...
>
> Proposed DetNet Charter
>
> The Deterministic Networking Working Group (DetNet) will focus on
> deterministic data paths that operate over Layer-2 Bridged and Layer-3
> routed segments, where such paths can provide bounded latency, loss and
> jitter. The Working Group will address Layer 3 aspects in support of
> deterministic applications. The group will collaborate with
> IEEE802.1TSN, which is responsible for Layer-2 operations, to define a
> common architecture to support IEEE802.1TSN applications. For the common
> architecture, a number of elements such as the IEEE802.1TSN host
> operation should be agnostic to the choice of network used for the
> connectivity.
>
> The Working Group will specify an overall architecture that encompasses
> the data plane, OAM, management, control, and security aspects that are
> required to enable a multi-hop path, and forwarding along that path,
> with the deterministic properties of controlled latency, low packet
> loss, low jitter, and high reliability. The work will apply to flows
> that can be characterized in a manner that allows the network to 1)
> reserve the appropriate resources for the flows in advance, and 2)
> release/reuse the resources when they are no more required.  The work
> will cover the characterization of flows, the encapsulation of frames,
> the required forwarding behaviors, as well as the state that may need to
> be established in intermediate nodes; it will not include end-to-end
> considerations such as transport protocols, modification of OAM, L3
> forwarding and encapsulations, or control plane protocols. Candidate
> Layer 3 data plane technologies that may be used, without modification,
> include: IPv4, IPv6, MPLS. As part of the overall architecture work, the
> working group will document which deployment environments and types of
> topologies that are within (or outside) the scope of the DetNet
> architecture.  This work focuses on the data plane and is independent
> from any path setup protocol or mechanism.  The data plane will be
> compatible with the work done in IEEE801.1TSN.
>
> DetNet is chartered to work in the following areas:
>
>  o Overall architecture: This work encompasses the data plane, OAM,
>    management, control, and security aspects.
>
>  o Data plane: This work will document a data plane method of flow
>    identification and packet forwarding over Layer 3.
>
>  o Data flow information model: This work will identify the information
>    needed for flow establishment and control and be used by a
>    reservation protocol or by YANG data models. The work will be
>    independent from the protocol(s) used to control the flows
>    (e.g. YANG, PCEP or GMPLS).
>
>  o Identification of additional YANG augmentations: This work will
>    document device and link capabilities (feature support) and resources
>    (e.g. buffers, bandwidth) for use in device configuration and status
>    reporting. Such information may also be used when advertising the
>    deterministic network elements to a control plane. The work will be
>    independent from the protocol(s) that may be used to advertise this
>    information (e.g. ISIS or GMPLS extensions). Any YANG work will be
>    coordinated with the working groups that define the base models.
>
>  o As needed, problem statement: This effort will establish the
>    deployment environment and deterministic network requirements which
>    is supported.
>
>  o As needed, vertical requirements: This effort will detail the
>    requirements for deterministic networks in various industries, for
>    example, professional audio, electrical utilities, building
>    automation systems, wireless for industrial applications.
>
> The WG will coordinate with other relevant IETF Working Groups,
> including CCAMP, PCE, PALS, TEAS, TSVWG, and 6TisSCH. As the work
> progresses, requirements may be provided to the responsible Working
> Group, e.g. PCE, TEAS, and CCAMP, with DetNet acting as a focal point to
> maintain the consistency of the overall architecture. The WG will liaise
> with appropriate groups in IEEE and other Standards Development
> Organizations (SDOs).
>
>
>
>
>

---

From: "Sexton, Daniel W (GE Global Research)" <[email-masked]>
Date: Wed, 2 Sep 2015 20:43:24 +0000

Charter looks like it has shaped up very nicely - no objection here.

Daniel Sexton
GE Global Research
One Research Circle
Niskayuna, NY
12309
O: 518-387-4121
M:518-424-5728
DC:*833-4121

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Wednesday, September 02, 2015 3:57 PM
To: DetNet
Cc: Pat Thaler; Jouni Korhonen; Pascal Thubert (pthubert)
Subject: Re: [Detnet] Draft charter discussion

https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_bof_trac_wiki_DetNetDraftCharter&d=BQICAg&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=TATOVI9o6SBtSMQwyNMaog&m=u9EjyESlRAz47wWZf2PUK1bd0WjSfOG8qkJIQPsnXR0&s=oVUGiSFd_K5LY5COy9OJyrKW6s61KFCwVd9q7M7AUw0&e= 

Lou

PS  It's really great to see al the discussion on topics for the WG, but please change the subject line -- and reserve it for discussions that may impact the charter text. - Thanks

On 8/26/2015 2:41 PM, Lou Berger wrote:
> I think we all recognize it isn't perfect, but it's a starting point 
> for the discussion.
>
> routed segments, where such paths can provide bounded latency, loss 
> and jitter. The Working Group will address Layer 3 aspects in support 
> of deterministic applications. The group will collaborate with 
> common architecture to support IEEE802.1TSN applications. For the 
> common architecture, a number of elements such as the IEEE802.1TSN 
> host operation should be agnostic to the choice of network used for 
> the connectivity.
>
> The Working Group will specify an overall architecture that 
> encompasses the data plane, OAM, management, control, and security 
> aspects that are required to enable a multi-hop path, and forwarding 
> along that path, with the deterministic properties of controlled 
> latency, low packet loss, low jitter, and high reliability. The work 
> will apply to flows that can be characterized in a manner that allows 
> the network to 1) reserve the appropriate resources for the flows in 
> advance, and 2) release/reuse the resources when they are no more 
> required.  The work will cover the characterization of flows, the 
> encapsulation of frames, the required forwarding behaviors, as well as 
> the state that may need to be established in intermediate nodes; it 
> will not include end-to-end considerations such as transport 
> protocols, modification of OAM, L3 forwarding and encapsulations, or 
> control plane protocols. Candidate Layer 3 data plane technologies 
> that may be used, without modification,
> include: IPv4, IPv6, MPLS. As part of the overall architecture work, 
> the working group will document which deployment environments and 
> types of topologies that are within (or outside) the scope of the 
> DetNet architecture.  This work focuses on the data plane and is 
> independent from any path setup protocol or mechanism.  The data plane 
> will be compatible with the work done in IEEE801.1TSN.
>
> Group, e.g. PCE, TEAS, and CCAMP, with DetNet acting as a focal point 
> to maintain the consistency of the overall architecture. The WG will 
> liaise with appropriate groups in IEEE and other Standards Development 
> Organizations (SDOs).
>
>
>
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_detnet&d=BQICAg&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQ
> YWSI&r=TATOVI9o6SBtSMQwyNMaog&m=u9EjyESlRAz47wWZf2PUK1bd0WjSfOG8qkJIQP
> snXR0&s=xN3U0YQ5kxja9F3lCDC0SiqhqbiocaexHyuzyAycRtQ&e=
>

_______________________________________________
detnet mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=BQICAg&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=TATOVI9o6SBtSMQwyNMaog&m=u9EjyESlRAz47wWZf2PUK1bd0WjSfOG8qkJIQPsnXR0&s=xN3U0YQ5kxja9F3lCDC0SiqhqbiocaexHyuzyAycRtQ&e=

---

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

I like Jouni’s words, but drop “are likely to”.

Allow me to stress that the primary goal is a guarantee of a maximum
latency, without simply dropping packets that would exceed that guarantee.
 Yes, some flows in some applications will have a need for a low value for
that guarantee.  But, when you stress very low latency, you quickly morph
the problem to a very different solution space.  I’d rather not put that
into the charter because it will cause confusion, down the line.  In every
solution I’ve seen, guaranteeing a latency maximum winds up making the
average latency worse.  That is NOT a bad thing!

— Norm

-----Original Message-----
From: detnet <[email-masked]> on behalf of Jouni Korhonen
<[email-masked]>
Date: Monday, August 31, 2015 at 07:42 AM
To: Pascal Thubert <[email-masked]>, Balázs Varga A
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Detnet] Draft charter discussion

>I tend to agree with Pascal. No issue from my side having
>"sub-milliseconds" mentioned as an example in the text. On the other hand
>we could say: "..with the deterministic properties of controlled low
>latency, low packet loss, low packet delay variation, and high
>reliability that are likely to greatly exceed the current expectations
>for IP protocols."
>
>- Jouni
>
>> From: detnet [mailto:[email-masked]] On Behalf Of Pascal
>>Thubert
>> (pthubert)
>> Sent: Monday, August 31, 2015 6:54 AM
>> ... But then, some do not need to, and for some others, the critically
>>is a time
>> sync in usecs, a low jitter, or a guarantee of no more than 3 losses in
>>a row. I'm
>> afraid that exhibiting one property may make it appear like more
>>important than
>> another. I find the charter balanced, but then, maybe we could use the
>>word
>> "extreme" or some equivalent to reflect that " paths can provide bounded
>> latency, loss and packet delay variation (jitter)" in ways that are
>>beyond the
>> traditional expectations of IP protocols.
>> 
>> What do you think?
>> 
>> Pascal
>> 
>>as
>> > many current protocols do not deal with such a timescale.
>> >
>> > Cheers
>> > Bala'zs
>> >
>>particularly
>> > important WRT PDV/jitter, I'm not sure this level of detail really
>>belongs in
>> > the charter.
>> >
>> > What do others think?
>> >
>> >