Re: [armd] Multicast in the data center [was Re: address resolution

Aldrin Isaac <aldrin.isaac@gmail.com> Wed, 15 February 2012 21:03 UTC

Return-Path: <aldrin.isaac@gmail.com>
X-Original-To: armd@ietfa.amsl.com
Delivered-To: armd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C5021F8570 for <armd@ietfa.amsl.com>; Wed, 15 Feb 2012 13:03:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.317
X-Spam-Level:
X-Spam-Status: No, score=-3.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhjeYokzpZwg for <armd@ietfa.amsl.com>; Wed, 15 Feb 2012 13:03:13 -0800 (PST)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id DB82121F8572 for <armd@ietf.org>; Wed, 15 Feb 2012 13:03:12 -0800 (PST)
Received: by qafi29 with SMTP id i29so3534311qaf.10 for <armd@ietf.org>; Wed, 15 Feb 2012 13:03:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=FreiXXu74sXWI7oLjEkMnrdCj3mmH4vlNZTeKP/qjVk=; b=fqHFQzhZoEZT1kUwN7d3dYboDMWXz0VmDZaHg/DLBae/uPRJphrqijjo+3p4kUBYSZ t4zGLblVDyzHG7YKSUSCRPvESS7hNZgMTyizHezz/FhFgllDSYKI3WAZ4gxnTgSsQOz4 Jhyro9EE+QeqJq0jocg0GZ7IQeC9j+SNSQCO4=
Received: by 10.229.136.19 with SMTP id p19mr16322302qct.133.1329339792425; Wed, 15 Feb 2012 13:03:12 -0800 (PST)
Received: from mymac.home (ool-44c1c730.dyn.optonline.net. [68.193.199.48]) by mx.google.com with ESMTPS id bd19sm12967243qab.17.2012.02.15.13.03.10 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Feb 2012 13:03:11 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset="us-ascii"
From: Aldrin Isaac <aldrin.isaac@gmail.com>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F632E1DF6C@dfweml505-mbx>
Date: Wed, 15 Feb 2012 16:03:09 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <3307C61A-5DA1-4A43-B807-095C3BBDB700@gmail.com>
References: <CA+-tSzzNeLP4N=Nv1EeBML51KTpmxPP3NWut+vnaWFy8RtUViA@mail.gmail.com> <7AE6A4247B044C4ABE0A5B6BF427F8E291E1A5@dfweml503-mbx> <CA+-tSzyvoDfwnKc7Yt65abQWSqMg2jF0iQax=wcYkmwtNGxZng@mail.gmail.com> <60C093A41B5E45409A19D42CF7786DFD522A9BE1F1@EUSAACMS0703.eamcs.ericsson.se> <CA+-tSzwZVYyEO62ngYGojwSrkSBBY2SWr93PDQmAp7a3y_7TMQ@mail.gmail.com> <CAL3FGfy0iyo_TTr-iuSzQuqRm8Li753UFWQsk=RGWh_nCdPMMw@mail.gmail.com> <CA+-tSzwFWBWd0_QZ4CqgQmjTUaXnBafNVdk8oZvK6oRTCR4Jqg@mail.gmail.com> <CAL3FGfwx=n9kKjwcARg6-ge2a-t-R+7RmR=d-qRJx=TdzNHMAQ@mail.gmail.com> <201202151407.q1FE7cWW022379@cichlid.raleigh.ibm.com> <4D9F477D-70C5-44B7-8146-992579B0D543@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F632E1DF6C@dfweml505-mbx>
To: Linda Dunbar <linda.dunbar@huawei.com>
X-Mailer: Apple Mail (2.1257)
Cc: Thomas Narten <narten@us.ibm.com>, "armd@ietf.org" <armd@ietf.org>
Subject: Re: [armd] Multicast in the data center [was Re: address resolution
X-BeenThere: armd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." <armd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/armd>, <mailto:armd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/armd>
List-Post: <mailto:armd@ietf.org>
List-Help: <mailto:armd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/armd>, <mailto:armd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Feb 2012 21:03:18 -0000

Hi Linda,

Yes, pub-sub is the same as publish-subscribe.  The publishers and subscribers are both in the same subnet and across subnets, even on opposite sides of of a WAN.  In fact many of the applications both publish and subscribe simultaneously.  Some applications use it for heart-beat and as bi-directional application control channels, while others use it to send fat (50Mbps to 1Gbps+) one-way data flows to many downstream recipients, and everything in between.  Multicast is generally organized into small, medium and large flow groups to manage state.  Small flows are generally ad-hoc (come and go at will) and forced to share a limited set of small flow groups.  Medium flow groups are shared by communities of interest.  Large flows get their own multicast groups to avoid excessive bandwidth use.  A PGM layer is used for reliable multicast.  Others will have different use-cases and operating models.  Bottom line -- multicast IS being used extensively in the DC, but not by run-of-the-mill applications.

-- aldrin

On Feb 15, 2012, at 9:53 AM, Linda Dunbar wrote:

> Aldrin, 
> 
> Is "pub-sub" same as "Publish-subscribe" related applications? 
> Are all the "subscribers" in the same subnet as the "publisher"? 
> If yes, it is almost like many multicast groups being created (in real time?), with subscribers subscribing to a subset of the multicast groups, isn't it? 
> If they are in different subnets, is it like L3 multicast?
> 
> Linda
> 
>> -----Original Message-----
>> From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of
>> Aldrin Isaac
>> Sent: Wednesday, February 15, 2012 8:40 AM
>> To: Thomas Narten
>> Cc: armd@ietf.org
>> Subject: Re: [armd] Multicast in the data center [was Re: address
>> resolution requirement from hosts to overlay edge nodes. Any opinion?]
>> 
>> Any DC with applications performing heavy pub-sub are more than likely
>> using multicast.  I am aware of many companies for whom multicast is
>> critical and enabled on their DC routers.
>> 
>> On Feb 15, 2012, at 9:07 AM, Thomas Narten wrote:
>> 
>>> Mike McBride <mmcbride7@gmail.com> writes:
>>> 
>>>> Large L2 overlay networks?  I don't know. Would be good to find out
>>>> from the community about performance and scalability of multicast in
>>>> the DC.
>>> 
>>> My impression is that many data centers do not enable IP multicast on
>>> their routers. That means you can use link-local multicast (which
>>> works fine within one IP subnet and doesn't really have scaling
>>> issues). But if you want multicast that goes beyond one link (and IP
>>> subnet), which is presumably necessary for an overlay like
>>> VXLAN/NVGRE, that is where you have problems.
>>> 
>>> The question is not even whether L3 multicast scales. It's whether
>> the
>>> DC operater is willing to enable such multicast.
>>> 
>>> Thomas
>>> 
>>> _______________________________________________
>>> armd mailing list
>>> armd@ietf.org
>>> https://www.ietf.org/mailman/listinfo/armd
>> 
>> _______________________________________________
>> armd mailing list
>> armd@ietf.org
>> https://www.ietf.org/mailman/listinfo/armd