Re: [MBONED] A concern about draft-acg-mboned-multicast-models recommendations

"James A. (Jim) Stevens" <james.a.stevens@rockwellcollins.com> Wed, 28 February 2018 20:22 UTC

Return-Path: <james.a.stevens@rockwellcollins.com>
X-Original-To: mboned@ietfa.amsl.com
Delivered-To: mboned@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1E512426E for <mboned@ietfa.amsl.com>; Wed, 28 Feb 2018 12:22:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 IukS-GixA9On for <mboned@ietfa.amsl.com>; Wed, 28 Feb 2018 12:22:26 -0800 (PST)
Received: from secvs02.rockwellcollins.com (smtpimr.rockwellcollins.com [205.175.225.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 057D5124BE8 for <mboned@ietf.org>; Wed, 28 Feb 2018 12:22:25 -0800 (PST)
X-RC-All-From: , 205.175.225.133, No hostname, james.a.stevens@rockwellcollins.com, "James A. (Jim) Stevens" <james.a.stevens@rockwellcollins.com>, ,
X-RC-Attachments: , ,
X-RC-RemoteIP: 205.175.225.133
X-RC-RemoteHost: No hostname
X-RC-IP-Hostname: secip02.rockwellcollins.com
X-RC-IP-MID: 200208941
X-RC-IP-Group: GOOGLE_RELAYED
X-RC-IP-Policy: $GOOGLE_RELAYED
X-RC-IP-SBRS: None
Received: from unknown (HELO mail-wr0-f198.google.com) ([205.175.225.133]) by secvs02.rockwellcollins.com with ESMTP/TLS/AES128-GCM-SHA256; 28 Feb 2018 14:22:17 -0600
Received: by mail-wr0-f198.google.com with SMTP id r15so2453359wrr.16 for <mboned@ietf.org>; Wed, 28 Feb 2018 12:22:17 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/ogYNmnmKwPJP0e2aYyACeysEYmJ4yhabfgikbi0Vvw=; b=mlEbFLLk3jn4rRGVm3H/NI2/HdYCVgd/RUt37eS+2XeGXPwL1yCzOBb4cs93xakc3n FaSGuES9z8/5oz/vk4As+vo9rbDgWqcNQu/yIUuqmVy8rSMQiCVP+dKl5NmUeb7bxBi5 wouTE0JLiryI/Pz240pdT+Y93+HsrNtpzCnw7HYxaffhM9qRixztyhAxhkFwNL80LkUp G0ChwrSVge6MmmxgSOD0s7icMw7d9q3qXm/lhWXIQvgZRa/4+1C2unAyZbqb/K4EWqMc BF0XvkwX4S9+1KqhtgDD7lhVwBEOc/w2KglfsMyHwwgbLp53PjUCDYKSphnqpO7X64V4 pETQ==
X-Gm-Message-State: APf1xPDgFJWRbgT/FNIQuaqfo0rRDTRURxaFDpuXOwOKf+QSSZmHUF5Y 1uHWAIO3xVBN0pgavytOaxuxd/+8VfsxRgKe/CPOF1Rv5yvRXYAzXOCOBHRiyntxXFLFXeUDe0m RXRwek1RCjfkNB4JwfugACZLGwY+raLlwApLQCumXfg==
X-Received: by 10.223.167.145 with SMTP id j17mr17199095wrc.121.1519849335805; Wed, 28 Feb 2018 12:22:15 -0800 (PST)
X-Google-Smtp-Source: AH8x224TahLoFno5x9aKmtD1MCanVlr+E2Vf6q6pRVMUBCF7IWCvzdeX4nebMI6Y9LXAlkDwDVJAPVG2tL1Nvi4iJOs=
X-Received: by 10.223.167.145 with SMTP id j17mr17199075wrc.121.1519849335330; Wed, 28 Feb 2018 12:22:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.168.151 with HTTP; Wed, 28 Feb 2018 12:22:14 -0800 (PST)
In-Reply-To: <CD402244-A3B3-4988-AB45-404B87DBEA94@jisc.ac.uk>
References: <CAH8Jh6DikQa-9Kft0WdyGZYCPjWLScNVtYce2=EyL1q+0rAYVg@mail.gmail.com> <20180227231838.GI67472@cs-it-6805697.local> <CD402244-A3B3-4988-AB45-404B87DBEA94@jisc.ac.uk>
From: "James A. (Jim) Stevens" <james.a.stevens@rockwellcollins.com>
Date: Wed, 28 Feb 2018 14:22:14 -0600
Message-ID: <CAH8Jh6CRvvREZXoXH4mw8WecdHCzsvbPt5tHoNQwPGLauCoXOg@mail.gmail.com>
To: Tim Chown <Tim.Chown@jisc.ac.uk>
Cc: "Dale W. Carder" <dwcarder@es.net>, "mboned@ietf.org" <mboned@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c1cd8bebeab5705664b7f71"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/ytB3xWFjaj7601FLhnHa3aGWJXU>
Subject: Re: [MBONED] A concern about draft-acg-mboned-multicast-models recommendations
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mboned/>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Feb 2018 20:22:29 -0000

Tim, Dale, Bert - thanks for your feedback and description of plans for the
next release(s) of the draft-acg-mboned-multicast-models-02 document.

I do not disagree with high-level recommendation about having RFC
deprecating use of ASM for interdomain.

I support the group's plan to separate the document into two documents -
one for deprecation of interdomain ASM and the other to provide current
best practice for multicast use makes sense.  For this second document, I
recommend that it include the intradomain use cases where ASM is better
solution than SSM as well as all the use cases where SSM is better.  The
ASM use case I described in my email is basically the same use case that
Toerless described in his Wed, 20 Dec 2017 19:10:03 +0100 email, namely
distributed apps with a lot of short-term multi-party group-transactions.

Regards,
Jim

On Tue, Feb 27, 2018 at 5:33 PM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:

> Hi,
>
> Thanks Dale.
>
> Yes, the general principle we agreed was on inter-domain deprecation. I
> suspect Jim has read the draft, but not caught up on the mail list, which
> if he's new here is only to be expected :)
>
> For intra-domain, what consenting adults do in their own networks is up to
> them, if it's constrained, but I do sense a wish to document
> recommendations for adoption of SSM intra-domain too, to explore what
> missing pieces there might be (e.g. around service discovery), and to
> understand for which applications ASM is still beneficial/preferred (which
> may include local applications with highly dynamic bidirectional
> participants).
>
> But I think it's important not to get lost in detail when making the
> high-level recommendation on inter-domain ASM, hence the split of the
> document, and my question in the previous email.
>
> Tim
>
> > On 27 Feb 2018, at 23:18, Dale W. Carder <dwcarder@es.net> wrote:
> >
> > Hi Jim!
> >
> > I think we're converging towards deprecating ASM for *inter-domain*
> > use, and what we say about intra-domain models is a bit in flux.
> >
> > I think the latest is at the bottom of Tim's most recent message:
> > https://www.ietf.org/mail-archive/web/mboned/current/msg02543.html
> >
> > glad to have you here!
> >
> > Dale
> >
> >
> > Thus spake James A. (Jim) Stevens (james.a.stevens@rockwellcollins.com)
> on Tue, Feb 27, 2018 at 04:29:00PM -0600:
> >> Hi, I’ve only recently joined MBONED, so this email may be rehashing old
> >> discussions. (If so, please just point me to the prior discussions.)
> >>
> >> With respect to multicast service models, I support customers who field
> >> hundreds to thousands of nodes where each node is a member of multiple
> >> (typically five to ten) multicast groups where most of the groups have
> >> dozens to hundreds of members that partially overlap in membership
> between
> >> the groups.  All of the members of the multicast groups are both
> multicast
> >> sources and receivers.  The nodes are spread out over multiple IP links
> >> (typically wireless).  The multicast groups are within a single IP
> routing
> >> domain that can contain dozens to hundred of IP links and subnets.  The
> IP
> >> links are typically other than standard WiFi or cellular IP links and
> have
> >> limited throughput capacity – ranging from tens of kilobits/sec to a few
> >> megabits/sec – so a key concern is to keep overhead down.
> >>
> >> For this multicast scenario with many dynamic bidirectional sources and
> >> receivers, we use ASM rather than SSM model to reduce management
> overhead
> >> and simplify source discovery by not having to track which nodes have
> >> joined which groups in order to do an SSM join to all the members of the
> >> group.
> >>
> >> The draft-acg-mboned-multicast-models-02 recommends “the use of SSM
> for all
> >> multicast scenarios.” For this multicast scenario, I don’t see how SSM
> >> efficiently satisfies this many multiple sources and receivers –
> especially
> >> since the multicast members are dynamically joining and leaving.
> >>
> >> Thus, I argue that SSM is not always the best multicast model and there
> >> shouldn’t be a blanket recommendation to use SSM for all possible
> multicast
> >> applications. In addition, I recommend section 7.6 address the fact that
> >> SSM is not as efficient as ASM for the case of many dynamic
> bidirectional
> >> sources and receivers.
> >>
> >> Or, am I overlooking something on how to use SSM to address scenarios
> with
> >> many dynamic bidirectional sources and receivers?
> >>
> >> Thanks,
> >>
> >> Jim Stevens
> >
> >> _______________________________________________
> >> MBONED mailing list
> >> MBONED@ietf.org
> >> https://www.ietf.org/mailman/listinfo/mboned
> >
> > _______________________________________________
> > MBONED mailing list
> > MBONED@ietf.org
> > https://www.ietf.org/mailman/listinfo/mboned
>
>


-- 
James A. (Jim) Stevens, PhD
Network Architect / Technical Fellow
Rockwell Collins Government Systems
james.a.stevens@rockwellcollins.com
972-705-3475 (office)
214-392-2273 (cell)