[DLNEX] Various sources contributing to E2E latency/delay-- Discussion of reliable and deterministic latency attributes

[Linda Dunbar <[e-mail]>]

Lou,

Change the subject to make the discussion more focused.

As of now, the DLNex is to explore what kind of characteristics can be exposed by network, or can be imposed by upper layer, to make the delay/latency of E2E services more predictable or more optimal. The final work may eventually fall into some existing IETF WGs. Here, I am just brainstorming some potential exposures:

This paper "Reducing Internet Latency: A Survey of Techniques and their Merits" (http://www.bobbriscoe.net/pubs.html#latency_survey ) listed multiple sources that contributing to Latency/delay for E2E services:

      The sources of delay are classified into five main categories: structural delays, interaction between endpoints, delays along transmission paths, delays related to link capacities, and intra-end-host delays.

      Structural delays arise from the structure of the network or the communication path that is used.
      The paper shows that one E2E service can use DNS multiple times. Therefore, where DNS is located is a big contributor to the overall latency. This could be a potential exposure by the network.

      Delays resulting from the interaction between endpoints include delays due to transport initialization and secure session initialization, as well as delays from recovering lost packets and from message-aggregation techniques
      Is it another exposure? Is there secure channel used?

      Delays along transmission paths captures the delays that may be encountered as data travels between a sender and a receiver.
      If some segments along the transmission paths are DetNet enabled or OIF’s FlexEthernet enabled, this definitely should be exposed. Then the upper layer can control/reserve the resource as CCAMP has done for MPLS paths and optical channels.

      Delays related to link capacities include both delays resulting from sharing limited capacity and delays from protocol inefficiencies that under-utilize capacity and therefore communication takes longer than necessary.
      I assume this is the type of work that CCAMP is to address.

      Intra-end-host delays are delays that occur internally within host endpoints. This includes delays due to buffering in the transport protocol stack and delays within the operating system.
      This is the end hosts TCP/UDP layer.

Linda

-----Original Message-----
From: Lou Berger [mailto:[e-mail]]
Sent: Thursday, October 20, 2016 2:36 PM
To: Linda Dunbar <[e-mail]>; Pat Thaler <[e-mail]>
Cc: Pascal Thubert (pthubert) <[e-mail]>; [e-mail]; Patrick Wetterwald (pwetterw) <[e-mail]>; Alia Atlas <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [Detnet] FW: New Non-WG Mailing List: DLNEX -- Discussion of reliable and deterministic latency attributes

Hi Linda,

    Could you (or anyone on DLNEX) elaborate on the type of documents you're thinking of delivering?

In detnet, we've so far been more focused on applications/use cases and data plane options.  But we're really looking forward to contributions/drafts on the information that is needed to support the control of deterministic flows.  The charter states this as:

    Data flow information model: This work will identify the
    information needed for flow establishment and control and be
    used by reservation protocols and YANG data models. The work
    will be independent from the protocol(s) used to control the
    flows (e.g. YANG+NETCONF/RESTCONF, PCEP or GMPLS).

Any drafts/contributions on this topic or willingness to help define these would be great.

If there are sufficiently developed ideas, we could probably even find time to discuss in our Seoul session.  (Or perhaps just informally, if there aren't.)

Thanks,
Lou

On 10/19/2016 7:09 PM, Linda Dunbar wrote:
>
> Pat,
>
>
>
> What you said is so true: “The network can't provide a bounded or
> deterministic latency to an unbounded flow”.
>
>
>
> DETNET charter starts with
>
> The Deterministic Networking (DetNet) Working Group focuses on
> deterministic data paths that operate over Layer 2 bridged and Layer 3
> routed segments, where such paths can provide bounds on latency, loss,
> and packet delay variation (jitter), and high reliability
>
>
>
> If I understand it correctly, DETNET focuses on the enabling
> technologies to ensure deterministic latency path across a set of nodes.
>
>
>
> E2E low latency services has many issues, such as:
>
> ·        There could be “bounded flows” that need low latency services
> mixed with other traffic in the network.
>
> ·        E2E services may have to go through many hops, links with
> some links not supporting DETNET.
>
> ·        there could be various protection/re-route mechanisms which
> all increase latency.
>
> ·        etc
>
>
>
> Some problems specific to WAN include how to isolate the various
> service traffic, and provide maximum manageability to upper layers.
>
>
>
> One company in NANOG asked why not use ICMP to mark the delay along
> the path to give upper link, ..
>
>
>
> Linda
>
>
>
>
>
> Linda
>
>
>
> *From:*Pat Thaler [mailto:[e-mail]]
> *Sent:* Wednesday, October 19, 2016 5:25 PM
> *To:* Lou Berger <[e-mail]<mailto:[e-mail]>>
> *Cc:* Alia Atlas <[e-mail]<mailto:[e-mail]>>; Patrick Wetterwald (pwetterw)
> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Pascal Thubert
> (pthubert) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
> Linda Dunbar <[e-mail]<mailto:[e-mail]>>
> *Subject:* Re: [Detnet] FW: New Non-WG Mailing List: DLNEX --
> Discussion of reliable and deterministic latency attributes
>
>
>
> We have been having recent discussions about latency such as what type
> of latency is important.
>
>
>
> As far as the "feasibility exercise for achieving reliable and
> deterministic latency through a network element or a segment" that
> overlaps very much what DetNet and IEEE 802.1 TSN have been doing. I
> believe we have already shown that it is feasible and are not on
> specifying how to do that. I'm concerned about the overlap between
> what that paragraph describes and our work.
>
>
>
> There could be useful work on communication from the upper layer of
> the flow characteristics, behavior and requirements. There probably is
> some gap to fill that would help our work. I'm concerned that the list
> description focuses only on exposing lower layer characteristics to
> the upper layer. The network can't provide a bounded or deterministic
> latency to an unbounded flow - to determine what latency can be
> provided, one has to know something about the bandwidth utilization of
> the flow.
>
>
>
> Regards,
>
> Pat
>
>
>
> On Wed, Oct 19, 2016 at 1:59 PM, Lou Berger <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Hi Alia,
>
>         Overlap looks likely.  I hope that when it does occur, you send
>     folks over here to contribute -- additional input / WG participation
>     would be great!  (For folks not familiar with DetNet, check out our
>     charter at https://datatracker.ietf.org/wg/detnet/charter/
>     <https://datatracker.ietf.org/wg/detnet/charter/>)
>
>     I expect we'll have some good data plane centric discussions at this
>     meeting, for those who may be interested (there's even still time to
>     submit related drafts!)
>
>     Cheers,
>
>     Lou
>
>     DetNet Co-chair
>
>     On 10/19/2016 11:46 AM, Alia Atlas wrote:
>     > Hi Patrick,
>     >
>     > The discussion intended on dlnex, a non-WG mailing list, is, I
>     think,
>     > broader - spanning the range of communications between upper layer
>     > applications and the network.  It is not clear yet what work might
>     > develop.  Be sure that I will be watching for any specific overlap
>     > with DetNet.
>     >
>     > I feel that it is useful to make it easy for groups to have a
>     list to
>     > brainstorm about their ideas before work is mature enough to
>     consider
>     > for standardization.
>     >
>     > Regards,
>     > Alia
>     >
>     > On Wed, Oct 19, 2016 at 8:17 AM, Patrick Wetterwald (pwetterw)
>     > <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20<mailto:[e-mail]>>
>     <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>     >
>     >     Can someone explain me why this mailing list is created
>     outside of
>     >     DetNet?
>     >
>     >     This sounds like a subset of Detnet no?
>     >
>     >     Thanks,
>     >
>     >     Patrick
>     >
>     >
>     >     On 19/10/2016, 07:56, "detnet on behalf of Pascal Thubert
>     >     (pthubert)" <[e-mail]
>     <mailto:[e-mail]>
>     >     <mailto:[e-mail]
>     <mailto:[e-mail]>> on behalf of [e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]>
>     >     <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>     >
>     >         From: IETF-Announce
>     [mailto:[e-mail]
>     <mailto:[e-mail]>
>     >     <mailto:[e-mail]
>     <mailto:[e-mail]>>] On Behalf Of IETF
>     Secretariat
>     >         Sent: mardi 18 octobre 2016 22:36
>     >         To: IETF Announcement List <[e-mail]
>     <mailto:[e-mail]>
>     >     <mailto:[e-mail] <mailto:[e-mail]>>>
>     >         Cc: [e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>;
>     >     [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>;
>     [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>     >     <mailto:[e-mail]
>     <mailto:[e-mail]>>
>     >         Subject: New Non-WG Mailing List: DLNEX -- Discussion of
>     >     reliable and deterministic latency attributes
>     >
>     >
>     >         A new IETF non-working group email list has been created.
>     >
>     >         List address:[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>     >         Archive:
>     >     https://mailarchive.ietf.org/arch/search/?email_list=dlnex
>
>     >     <https://mailarchive.ietf.org/arch/search/?email_list=dlnex>
>     >         To subscribe:
>     https://www.ietf.org/mailman/listinfo/dlnex
>     <https://www.ietf.org/mailman/listinfo/dlnex>
>     >     <https://www.ietf.org/mailman/listinfo/dlnex>
>     >
>     >         Purpose:
>     >         DLNEX is to discuss various latency characteristics that can
>     >     be exposed by network elements or segments and to explore if
>     there
>     >     are any latency related attributes that can be utilized by upper
>     >     layer. For example, could there be latency exposure that upper
>     >     layer can utilize to plan how to distribute their content to the
>     >     right edges to achieve optimal user experience? Or something
>     used
>     >     by Interactive AR controller to optimize their services? Is
>     there
>     >     any value gained by upper layer expressing that they would
>     rather
>     >     have fixed latency than losing packets?
>     >
>     >         The discussion is to answer questions like: are there any
>     >     effective interaction/coordination between upper layer and lower
>     >     layer to achieve more efficient optimization for latency
>     sensitive
>     >     services?
>     >
>     >         This discussion group is also a place to showcase the
>     state of
>     >     the arts in latency optimized switching architecture and
>     interface
>     >     designs, as the feasibility exercise for achieving reliable and
>     >     deterministic latency through a network element or a segment.
>     >     Those latency exposures are the foundation for (future) latency
>     >     optimized control plane.
>     >
>     >
>     >         For additional information, please contact the list
>     >     administrators.
>     >
>     >         _______________________________________________
>     >         detnet mailing list
>
>     >         [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     >         https://www.ietf.org/mailman/listinfo/detnet
>     >     <https://www.ietf.org/mailman/listinfo/detnet>
>     >
>     >
>     >     _______________________________________________
>     >     detnet mailing list
>     >     [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     >     https://www.ietf.org/mailman/listinfo/detnet
>
>     >     <https://www.ietf.org/mailman/listinfo/detnet>
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > detnet mailing list
>     > [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>     > https://www.ietf.org/mailman/listinfo/detnet
>
>     _______________________________________________
>     detnet mailing list
>     [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/detnet
>
>
>
>
>
> _______________________________________________
> detnet mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/detnet