Re: [pim] [MBONED] Detnet WG charter ? “QOS and Jumbo frames” over public internet

Gyan Mishra <hayabusagsm@gmail.com> Tue, 28 July 2020 13:13 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2303A0C71; Tue, 28 Jul 2020 06:13:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, 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 j3HHu33cBySE; Tue, 28 Jul 2020 06:13:26 -0700 (PDT)
Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 ED1373A0C75; Tue, 28 Jul 2020 06:13:22 -0700 (PDT)
Received: by mail-ua1-x934.google.com with SMTP id n4so6469676uae.5; Tue, 28 Jul 2020 06:13:22 -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=7NrI+tRklCD78k+gMBeRTgiwk+b3uLh0x78i/cFrPvs=; b=klleglK9NxEu/zLyJxEnIJNesbyBAbqsN/0JUxmVu7g+TWKqhm0tFGgmnFNnF3etoL 5KuP/rHuqzXvxdW+aa4e0kbkDd/WjCdPY9wU/FrcTxCCUYbtsRja6ra90sVhNnIrGw95 hJf7hnN15mjCPQVbXyzaSrESd9tazVcIk9DFEPyUVI35/MInxwlfldjB+udHopzosUJh MiezkF7d7gU8syeoGO78teGhmS56GCTf2e/oSK3tk//86EI5j89CkZK9R5UP/xIDUes2 +rXf9ja+dzHkknn6V3C4gupJ1ZPSCFVwxM9C02JZ/HukGFhWnBL0AWnmPVWRNVrydbK4 P7Ow==
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=7NrI+tRklCD78k+gMBeRTgiwk+b3uLh0x78i/cFrPvs=; b=XJImPVshkpenUhHKDIacIQX+c8nekreemDKMLW6Hs322BpvV6n1Z0OyuIDbJeJ0Qwy OCj+lMpnQ78T5B5N4CHEjM6tdjW8T+8owZDRvsg+kngpDnwJP2O/VDR/11if+lfkD4rQ ckF259/eGJxUej1keH6WMz4MUs/Tp4lNcptujWe6Eq7j4iHS1XCtKgSUOW9wU+VChmCc Bk9mU3w/GaszS8d0qNJYboRBtXMsCjhxx+SDQKp/IZUyW1avhxRNJ1sGJDxY7fo5C/yi Nl/ne0RSr5ogP6gA9P//Xa5Qro/eXu2gnpEoRFJtF6ufLgyMvVzHM8QVW8Me7gDde19B MO4g==
X-Gm-Message-State: AOAM530s4E/dHBxFWktcN2KJ0aeNn+nKkY8mUTLY9RydZ6i7n7Mp6g1M c7ALeryNWgsPSHAUThT/KnGuLT/HxAGQY73x260=
X-Google-Smtp-Source: ABdhPJy3jw4FpVPl/MQAexLHaXXcPKMfisxr1lEZAIWRQt9EmeOsBNNPCDxxIAYS3gtrpYeNKMN3UqFeRx0lOpn20N8=
X-Received: by 2002:ab0:48c8:: with SMTP id y8mr19225574uac.114.1595942001316; Tue, 28 Jul 2020 06:13:21 -0700 (PDT)
MIME-Version: 1.0
References: <CABNhwV0e40PFiAa3ohrSBqDbTutaYAQEykjCOJ8MY9=AbMYzEQ@mail.gmail.com> <BYAPR13MB2582DA1EDAD736FB3E844563F4730@BYAPR13MB2582.namprd13.prod.outlook.com>
In-Reply-To: <BYAPR13MB2582DA1EDAD736FB3E844563F4730@BYAPR13MB2582.namprd13.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Tue, 28 Jul 2020 09:12:43 -0400
Message-ID: <CABNhwV004DCCceMa=3M=DBuraAh9UU1-Tb63Wn-edT3rfwhPaA@mail.gmail.com>
To: Michael McBride <michael.mcbride@futurewei.com>
Cc: MBONED WG <mboned@ietf.org>, "detnet@ietf.org" <detnet@ietf.org>, "pim@ietf.org" <pim@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000012186b05ab803456"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/141cQgEEPa1bzUhudOt6Fcq8LXo>
Subject: Re: [pim] =?utf-8?q?=5BMBONED=5D_Detnet_WG_charter_=3F_=E2=80=9CQOS_?= =?utf-8?q?and_Jumbo_frames=E2=80=9D_over_public_internet?=
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jul 2020 13:13:38 -0000

I do recall PGM about 15+ years ago  a few vendor implemented it I believe
Cisco & Juniper.  I reviewed the draft for some more talking points for
today's discussion.

Thanks

Gyan

On Mon, Jul 27, 2020 at 11:10 PM Michael McBride <
michael.mcbride@futurewei.com> wrote:

> Hi Gyan,
>
>
>
> Please take a quick glance at RFC 5740 (NORM) and 3208 (PGM). We had a
> reliable multicast transport (rmt) wg, now closed, which put out some good
> rfc’s (https://datatracker.ietf.org/wg/rmt/documents/) which may be a
> good starting point for future work. Maybe it’s time to revisit this?  Talk
> to you tomorrow.
>
>
>
> mike
>
>
>
>
>
> *From:* MBONED <mboned-bounces@ietf.org> *On Behalf Of *Gyan Mishra
> *Sent:* Thursday, July 23, 2020 1:27 PM
> *To:* MBONED WG <mboned@ietf.org>rg>; detnet@ietf.org; pim@ietf.org
> *Subject:* [MBONED] Detnet WG charter ? “QOS and Jumbo frames” over
> public internet
>
>
>
>
>
> Dear Detnet WG
>
>
>
> + PIM & MBONED ( As the ? relates to reliable multicast video delivery
> over the internet or 4G/5G RAN backhaul for reliable multicast over mobile
> devices as well as simultaneously massive data transfers and how to make
> feasible)
>
>
>
> I was curious if Detnet as it appears relevant to the charter to provide
> reliable voice and video delivery over the public internet.
>
>
>
> Their have been many white papers by universities and research
> institutions over the years related to how to make end to end QOS possible
> over the global internet.
>
>
>
> Historically the problem has always been that all providers have their own
> QOS policy and its impractical to be able to come up with a standard
> queuing standards that all ISPs throughout the hierarchical internet must
> follow from Tier 1 down to the broadband carriers so that multicast can
> thrive on the internet.
>
>
>
> I don’t think it’s impossible and maybe a ubiquitous standard exists
> exists that all providers must follow today but I am not aware of one.
>
>
>
> The conceptual idea is that in this day and age precluding the concept of
> net neutrality or not as that opens up another can of worms - In theory it
> seems possible to have a standard way of WRR IPV4 IPV6 dscp based or IPV6
> future flow label field to provide end to end QOS guarantees for voice and
> video and reliable multicast delivery over the internet.  This would help
> UDP RTP multicast tremendously so that I-frame does not get dropped
> resulting in buffering issues pervasive and show stopper for best effort
> class dscp 0 multicast over the internet.
>
>
>
> If a QOS queuing standard does not exist today across the internet which
> WG do you think the standard should fall?
>
>
>
> I figured I would start with Detnet w/ CC to MBONE and PIM.
>
>
>
> Another idea which is orthogonal but related to end to end Jumbo and jumbo
> grams over the internet for high speed data transfers end to end..
>
>
>
> I stated orthogonal as due to FIFO queuing serialization delays w/o
> pipelining architecture QOS WRR and SP queue, voice and video would suffer
> from Jumbo - understood.  However if end to end QOS was possible over the
> global internet you could in theory essentially have your cake and eat it
> to so to speak.  Meaning with QOS voice and video let’s say could sit in EF
> and futuristic IPV6 Jumbo grams 4.2G payload bulk transfers could sit in a
> separate WRR AF queue end to end across the internet for both flow types.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
> --
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C0bab63d5e18b49bafa6308d82f46e59a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637311328847561602&sdata=iVsgI1D%2BpQqEdF39uRuiCLCoEgd4l3LY31AiBISXJao%3D&reserved=0>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike  *Silver Spring, MD
>
>
>


-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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