Re: [Detnet] Questions about the Networks in DetNet charter

Gyan Mishra <hayabusagsm@gmail.com> Tue, 07 July 2020 04:04 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2683A05A4; Mon, 6 Jul 2020 21:04:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfbfGAiSphFq; Mon, 6 Jul 2020 21:04:49 -0700 (PDT)
Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60AEB3A059F; Mon, 6 Jul 2020 21:04:49 -0700 (PDT)
Received: by mail-il1-x134.google.com with SMTP id o3so17434604ilo.12; Mon, 06 Jul 2020 21:04:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zI9x18iIscmiFgMme28687qbOjUPrmoXnjk0cCvE0ww=; b=ienbChcjBkEKb+qAknmFi2hRtrGC02eX3IaweaaSnWsuLlexsmlF5bX14Zz+dGMfi7 NEfGKMCkcGNJi+5A4SCozs87QRIX/yIuw/pFOe+XW+8ThI9iOhjbYgJ49A2A8VNdTTU5 CD9V3RSbcGJvEOz9kozpx0vK2ghtHrUUXHR7kzp4qzMZ4UPlkS7vxiqlh5ce6BTX865A 7XESjiRvsCVl54IZ/PHDyJGdiNWcOo5AbX1c2QNaA5NvHR8YqprBYBPx8BKb0fW2BBBt 8CZawbh/xcQfN1okvUdkYTq15Yi7/K54KRP8i58M6SX5a61+/K7btIOOCye2jPwJHyB1 5Wxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zI9x18iIscmiFgMme28687qbOjUPrmoXnjk0cCvE0ww=; b=GnKFRynvnZj9Y0qyIQaIXrY9I77xsClg+wC6SjlWUcGsV703zzXc28yub10h7SOFF5 MlqnVq6+8okoDqLwbROS/3ZasyDx2ppU/ZDHUIhxv4UCyWj575SkAHWEK1fQdTciWVf+ syA+j9SwUNxW30HXoGBbrTIxOm9mMa6kn34W5Pj+3pWX9Fu+S7tU2+rWIuHTqat5Dco+ SLcBfRZof0l5qqoF3JSKQNor6MlsEvIFRnvegfvAKAjvfXxtuhpUpYO9KeKPgWAIta41 a9Wri2lKnAcKCFXknGFuO7xBLHomnC/6wf0TAHVYL9Oc8NRKXmMzDUazPymNc9eVZrti ZrNw==
X-Gm-Message-State: AOAM53357I9spgxcJ40NSmr3KHclBEXjXepfFJMnNbHRE7GournvChd9 ArKzLHzuMfJEZSi4yrTpgxaD7U0lEjUmsTSiCHn71iKABkk=
X-Google-Smtp-Source: ABdhPJyWVnY050n2jZZiJfwt2jYc3M7jAAz4/QXZOmfUrftJFLCknt/s9Puq++0ybYe22WobQ+weAQ04q4zSB1AanRg=
X-Received: by 2002:a92:dd02:: with SMTP id n2mr33968809ilm.257.1594094688349; Mon, 06 Jul 2020 21:04:48 -0700 (PDT)
MIME-Version: 1.0
References: <202006221028453198858@zte.com.cn> <AM7PR07MB6994297E99322D6796E4A46EF2970@AM7PR07MB6994.eurprd07.prod.outlook.com> <AM7PR07MB69948C5CFC5F8FAF1FBFA929F2910@AM7PR07MB6994.eurprd07.prod.outlook.com> <CABNhwV2FMdv9LN1i49W562f78LKwBKGuiBq+t2cyMW3h+3t8pw@mail.gmail.com> <CABNhwV2ygWPEFtuorbn6XmugckiUwXUepTwygh1dpD=0M3Wa1Q@mail.gmail.com> <CABNhwV1Fud-7Ao-LLw6V-8bMEX5QnesuTtu+MXVkAdonx83rjA@mail.gmail.com> <CABNhwV0=4gshH5-ma+=7+OGgP26QU1UxMxKFXsjpdTRbuAarxQ@mail.gmail.com> <618b14a5-8363-b814-e1d9-24da90749990@labn.net>
In-Reply-To: <618b14a5-8363-b814-e1d9-24da90749990@labn.net>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Tue, 07 Jul 2020 00:04:37 -0400
Message-ID: <CABNhwV0z+1JetLoVZwwicjK4f=owLBBNxy_94SkODQQkZS0Xkw@mail.gmail.com>
To: Lou Berger <lberger@labn.net>
Cc: "detnet-chairs@ietf.org" <detnet-chairs@ietf.org>, "detnet@ietf.org" <detnet@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a3323d05a9d2176b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/RbxJKxZpueSLaep3Bgi6rlegr3M>
Subject: Re: [Detnet] Questions about the Networks in DetNet charter
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jul 2020 04:04:52 -0000

Lou

Thank you for responding to my questions.

That is exactly what I was looking for.


3.5.1.5 <https://tools.ietf.org/html/draft-ietf-detnet-data-plane-framework-06#section-3.5.1.5>.
Load sharing

   Use of packet-by-packet load sharing of the same DetNet flow over
   multiple paths is not recommended except for the cases listed above
   where PREOF is utilized to improve protection of traffic and maintain
   order.  Packet-by-packet load sharing, e.g., via ECMP or UCMP,
   impacts ordering and possibly jitter.


>From a network load balancing perspective most operators, both service
providers and enterprises have voice and video as well as data that rides
the common converged network for years now, and so “source / destination”
per flow based hardware switching load balancing  is the standard for
almost every vendor.  With Flow based load balancing all packets that are
part of the same source / destination flow are hashed to the same path via
the vendors ECMP hash algorithm which is usually an source / destination
XOR.  So flow based load balancing flows since all packets traverse the
same path are not subject to out of order packets or latency and jitter.
However, QOS end to end is a must for both unicast and multicast voice and
video as all traffic is RTP/UDP based to prevent queueing and head of line
blocking with small packets queuing up behind large packets.

In the past,  older routers has the option to do per packet load balancing
process switched, but due to issues with processing per packet in software
platforms as well as latency and jitter and out of order packets most if
not all vendors have moved away from per packet load balancing to hardware
based platforms flow based ECMP.

So my point was as to the name of the WG “Detnet” as deterministic voice
and video latency and jitter sensitive flows would get same path source /
destination address which has existed for 25+ years now by most vendors
hardware switched  flow based ECMP and all voice and video plays nicely and
is works well.

The concept of per packet load balancing  is really graconian in my mind
and non existent.

Kind regards

Gyan

On Mon, Jul 6, 2020 at 3:20 PM Lou Berger <lberger@labn.net> wrote:

>
> On 7/5/2020 10:35 PM, Gyan Mishra wrote:
> > Detnet WG
> >
> > I did not hear back anything on this question I had so was just
> > wondering on the correlation between Detnet and non ECMP type flows.
>
> Hi,
>
> multiple documents recommend against use of ECMP, e.g.,
> draft-ietf-detnet-data-plane-framework:
>
>
>           3.5.1.5
>           <
> https://tools.ietf.org/html/draft-ietf-detnet-data-plane-framework-06#section-3.5.1.5
> >.
>           Load sharing
>
>
>
>     Use of packet-by-packet load sharing of the same DetNet flow over
>     multiple paths is not recommended except for the cases listed above
>     where PREOF is utilized to improve protection of traffic and maintain
>     order.  Packet-by-packet load sharing, e.g., via ECMP or UCMP,
>     impacts ordering and possibly jitter.
>
> also, see https://www.google.com/search?q=draft-ietf-detnet+ecmp
>
> >
> > Also it does state in the charter but how was the WG name Detnet history?
>
> I'm not sure what the question is here.
> https://datatracker.ietf.org/wg/detnet has the history and record for
> past meetings and activities.
>
> Lou
>
> >
> > Kind Regards
> >
> > Gyan
> >
> > On Sun, Jun 28, 2020 at 6:51 PM Gyan Mishra <hayabusagsm@gmail.com
> > <mailto:hayabusagsm@gmail.com>> wrote:
> >
> >
> >     Deterministic networking by definition means the inbound and
> >     outbound paths use the same set of nodes and links for the flow.
> >
> >     So generally that means no ECMP per packet or per flow as IP ECMP
> >     is traditionally an XOR source/destination hash and so is deemed
> >     non deterministic predictable path taken by a flow.
> >
> >     Thanks
> >
> >     Gyan
> >
> >     On Sun, Jun 28, 2020 at 6:17 PM Gyan Mishra <hayabusagsm@gmail.com
> >     <mailto:hayabusagsm@gmail.com>> wrote:
> >
> >
> >         My last paragraph related to my question fixed.
> >
> >         I noticed in the charter or RFC 8578 does not mention non ECMP
> >         routing as deemed deterministic routing used in Detnet.
> >
> >         Thanks
> >
> >         Gyan
> >
> >         On Sun, Jun 28, 2020 at 6:01 PM Gyan Mishra
> >         <hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>> wrote:
> >
> >
> >             I had a generic question related to the Detnet WG charter.
> >
> >             So I understand the focus of latency and jitter time
> >             sensitive applications such as voice and video over any
> >             single administrative domain which is covers am any
> >             carriers network including RAN 4G/5G.  Am good with all that.
> >
> >             To me the term “deterministic” from a network routing
> >             perspective historically precluded ECMP flow based load
> >             balancing or for example vxlan source port entropy IP ECMP
> >             load balancing.   Since IP ECMP load balancing is all flow
> >             based technically UDP voice and video flows are not
> >             impacted as IP ECMP is prevalent in most all providers and
> >             enterprises.  In the past, IP per packet load existed and
> >             that reeked havoc with voice and video UDP RTP based flows
> >             out of order packets.  Since then most vendors due to
> >             issues with per packet load balancing over multiple paths
> >             have been eliminated.
> >             In my mind anything other then per packet load balanced
> >             flows is deterministic.
> >
> >             Deterministic routing I would think means in the simplest
> >             sense a non load balanced single path with no ECMP along
> >             the entire path.  Another way to look at is that you can
> >             see the flow along any hop in the path if you did a packet
> >             capture where non deterministic path for a flow that would
> >             not be possible.
> >
> >             I noticed in the charter it does mention ECMP Verdi’s not
> >             or in RFC 8578.
> >
> >             What does the deterministic mean in the context of the WG
> >             framework as it does not seem related to deterministic
> >             routing.
> >
> >
> >             Kind Regards
> >
> >             Gyan
> >
> >             On Sun, Jun 28, 2020 at 5:35 PM Janos Farkas
> >             <Janos.Farkas=40ericsson.com@dmarc.ietf.org
> >             <mailto:40ericsson.com@dmarc..ietf.org>> wrote:
> >
> >                 Hi Quan.
> >
> >                 This was my previous response.
> >
> >                 Best regards,
> >
> >                 Janos
> >
> >                 *From:* Janos Farkas
> >                 *Sent:* Monday, June 22, 2020 10:54 AM
> >                 *To:* xiong..quan@zte.com.cn
> >                 <mailto:xiong.quan@zte.com.cn>
> >                 *Cc:* detnet-chairs@ietf.org
> >                 <mailto:detnet-chairs@ietf.org>; lberger@labn.net
> >                 <mailto:lberger@labn.net>; gregory.mirsky@ztetx.com
> >                 <mailto:gregory.mirsky@ztetx.com>
> >                 *Subject:* RE: Questions about the Networks in DetNet
> >                 charter
> >
> >                 Hi Quan.
> >
> >                 The main purpose of the cited sentence is to limit the
> >                 scope of the work to make it reasonable, i.e., not
> >                 trying to boil the ocean. Actually, the main message
> >                 is that DetNet is not for the big I Internet, but for
> >                 smaller networks than that.
> >
> >                 Networks like mobile backhaul are definitely in scope
> >                 of DetNet. It is actually explicitly there in the
> >                 DetNet Use Cases
> >                 https://tools.ietf.org/html/rfc8578#section-6.2.2.
> >
> >                 Best regards,
> >
> >                 Janos
> >
> >                 *From:* xiong.quan@zte.com.cn
> >                 <mailto:xiong.quan@zte.com.cn> <xiong.quan@zte.com.cn
> >                 <mailto:xiong.quan@zte.com.cn>>
> >                 *Sent:* Monday, June 22, 2020 4:29 AM
> >                 *To:* detnet-chairs@ietf.org
> >                 <mailto:detnet-chairs@ietf.org>; Janos Farkas
> >                 <Janos.Farkas@ericsson.com
> >                 <mailto:Janos.Farkas@ericsson.com>>; lberger@labn.net
> >                 <mailto:lberger@labn.net>
> >                 *Cc:* gregory.mirsky@ztetx.com
> >                 <mailto:gregory.mirsky@ztetx.com>
> >                 *Subject:* Questions about the Networks in DetNet charter
> >
> >                 Dear Chairs,
> >
> >                 I noticed that in DetNet Charter, it mentions that the
> >                 networks which WG foucs on as following shown.
> >
> >                 "The Working Group will initially focus on solutions
> >                 for networks that are under a single administrative
> >                 control or within a closed group of administrative
> >                 control; these include not only campus-wide networks
> >                 but also can include private WANs. The DetNet WG will
> >                 not spend energy on solutions for large groups of
> >                 domains such as the Internet."
> >
> >                 Could you please clarify that the WAN  such
> >                 as Metropolitan area network and Mobile backhaul
> >                 network is included in DetNet use case or not?
> >
> >                 And does the DetNet WG only focus on the small
> >                 networks similier with TSN?
> >
> >                 Your reply is important and appreciated.
> >
> >                 Thanks,
> >
> >                 Quan
> >
> >                 _______________________________________________
> >                 detnet mailing list
> >                 detnet@ietf.org <mailto:detnet@ietf.org>
> >                 https://www.ietf.org/mailman/listinfo/detnet
> >
> >             --
> >
> >             <http://www.verizon.com/>
> >
> >             *Gyan Mishra*
> >
> >             /Network Solutions A//rchitect /
> >
> >             /M 301 502-1347
> >             13101 Columbia Pike
> >             /Silver Spring, MD
> >
> >
> >         --
> >
> >         <http://www.verizon.com/>
> >
> >         *Gyan Mishra*
> >
> >         /Network Solutions A//rchitect /
> >
> >         /M 301 502-1347
> >         13101 Columbia Pike
> >         /Silver Spring, MD
> >
> >
> >     --
> >
> >     <http://www.verizon.com/>
> >
> >     *Gyan Mishra*
> >
> >     /Network Solutions A//rchitect /
> >
> >     /M 301 502-1347
> >     13101 Columbia Pike
> >     /Silver Spring, MD
> >
> >
> > --
> >
> > <http://www.verizon.com/>
> >
> > *Gyan Mishra*
> >
> > /Network Solutions A//rchitect /
> >
> > /M 301 502-1347
> > 13101 Columbia Pike
> > /Silver Spring, MD
> >
> >
> >
> > _______________________________________________
> > detnet mailing list
> > detnet@ietf.org
> > https://www.ietf.org/mailman/listinfo/detnet
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD