Re: [MBONED] deploying internet-wide multicast (RE: deprecating MSDP)
"Holland, Jake" <jholland@akamai.com> Wed, 08 November 2017 18:22 UTC
Return-Path: <jholland@akamai.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 601301294F7 for <mboned@ietfa.amsl.com>; Wed, 8 Nov 2017 10:22:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 nyL4mBBKWZwE for <mboned@ietfa.amsl.com>; Wed, 8 Nov 2017 10:22:28 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 2A490129576 for <mboned@ietf.org>; Wed, 8 Nov 2017 10:22:28 -0800 (PST)
Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA8IMI6r004327; Wed, 8 Nov 2017 18:22:26 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=4foqAEwW7qPDQsJKXkCR9Gh5pCMjM7JDYeOkHG8XuOQ=; b=A2cwRlW+VI8/C1U6b5fQEvs6T6WRZWy1HKbii+QWWQHCmu65vG2sX46Kn+KW0iKfIDAT prcqNJwCfW+dWYayS0xYXC7v6ZR0N9RU86CmY2GO/t3E360E0+vxwz1wFLOmTEBVzZLl nhf5ih49hbOVld0BcXm4BM0A0OAcgjnQKz3nhRDz2hHynSqIJZFN+Dz2MU9k1e+03kq9 07Vi0vUU+oXUZqm/v70qSInh1P9KQs9WN0JEv3TgVTDGEqShjiKpnU0494C+vP7uv/h4 JzQtcABUbmxGU+RE5Y0keRyI7hmq8XWJeC+sKAHEhib1cTDqGmru5drIgLvclt7z8RnN Fg==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2e3nkn3qgs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Nov 2017 18:22:26 +0000
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vA8IIvNu014329; Wed, 8 Nov 2017 13:22:25 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2e18vue18j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 08 Nov 2017 13:22:24 -0500
Received: from usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 8 Nov 2017 13:22:23 -0500
Received: from usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) by usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) with mapi id 15.00.1263.000; Wed, 8 Nov 2017 13:22:23 -0500
From: "Holland, Jake" <jholland@akamai.com>
To: Stig Venaas <stig@venaas.com>, Mikael Abrahamsson <swmike@swm.pp.se>
CC: "mboned@ietf.org" <mboned@ietf.org>
Thread-Topic: [MBONED] deploying internet-wide multicast (RE: deprecating MSDP)
Thread-Index: AQHTKFDU/aqwdbbq5kmpwFCfY4/mJKMKPziAgACyAgCAAGTJgP//pBoA
Date: Wed, 08 Nov 2017 18:22:23 +0000
Message-ID: <ECC976E8-2633-45C1-A46C-F706DADD184F@akamai.com>
References: <20170725221330.GA4821@cs-it-6805697.local> <alpine.DEB.2.02.1707260908550.29724@svl-jtac-lnx02> <20170904141235.GC3194@faui40p.informatik.uni-erlangen.de> <alpine.DEB.2.02.1709051358300.14937@svl-jtac-lnx02.juniper.net> <f911d57bf77245b8b074d3c557ab28f2@XCH15-06-11.nw.nos.boeing.com> <alpine.DEB.2.20.1709060825330.29378@uplift.swm.pp.se> <20170907134500.GB23219@faui40p.informatik.uni-erlangen.de> <alpine.DEB.2.20.1709071602420.29378@uplift.swm.pp.se> <alpine.DEB.2.02.1709071111270.19087@svl-jtac-lnx02.juniper.net> <alpine.DEB.2.20.1709072213470.29378@uplift.swm.pp.se> <bd1f3dab5846485a89bf443bd17b5ec4@XCH15-06-11.nw.nos.boeing.com> <alpine.DEB.2.20.1709080445130.29378@uplift.swm.pp.se> <CAHANBt+G3EAOqmntE7O2dZddq_CXdEjcw62F_VE6ShLWEswWjg@mail.gmail.com> <alpine.DEB.2.20.1711081040500.16389@uplift.swm.pp.se> <CAHANBtL8q16ZBLL6dgkirVg4GwXW7v40G26Q5DYdNnBO_XW22Q@mail.gmail.com>
In-Reply-To: <CAHANBtL8q16ZBLL6dgkirVg4GwXW7v40G26Q5DYdNnBO_XW22Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.24.1.170721
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.112.167]
Content-Type: text/plain; charset="utf-8"
Content-ID: <FA5B5E7005F9DD468FC6BBA6906BA285@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-08_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711080242
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-08_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711080244
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/sd0r01wKWba_PkTazjcvIPhsaOU>
Subject: Re: [MBONED] deploying internet-wide multicast (RE: deprecating MSDP)
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, 08 Nov 2017 18:22:30 -0000
Hi, FLUTE and NORM are the reliable multicast transports I’ve seen: https://tools.ietf.org/html/rfc6726 https://tools.ietf.org/html/rfc5740 AFAIK neither has wide usage, but there’s implementations: http://mad.cs.tut.fi/download.html https://www.nrl.navy.mil/itd/ncs/products/norm If I understand correctly, Cablelabs’s IP Multicast ABR system uses a sort of bastardized version of NORM with a path for out-of-band unicast repair that doesn’t let receivers prevent the transmit window from sliding forward, since the streaming video use case can’t use the norm approach of letting receivers slow down the transmit: https://apps.cablelabs.com/specification/?category=VIDEO&subcat=IP%20MULTICAST&query=&doctype=&content=false&archives=false There’s some more speculative ongoing work I know of that might be relevant. https://tools.ietf.org/html/draft-pardue-quic-http-mcast-01 https://tools.ietf.org/html/draft-ietf-tsvwg-rlc-fec-scheme-01 I think FLUTE or NORM implementations could be made to work today for a non-time-critical download service, if there were multicast connectivity. I agree with Mikael that there’s more work to do before ordinary implementations of open standards can be used to operate a video service over multicast IP. I do want to operate a multicast video service, but not without FEC or some kind of repair. I also agree that AMT can be a helpful way to get multicast IP over wifi as unicast at layer 2 (though I would rather see native multicast to the home and either AMT relay or DMS (or both) at the wifi router, instead of AMT relays in the ISP, because multicast can help a lot on the access network for PON or CMTS, though I do take the point that in some cases relay in the ISP is more practical to deploy). But I agree with Stig that it’s not very helpful to make AMT reliable, as compared to making a sufficiently reliable multicast transport protocol that can work for streaming video. -Jake On 11/8/17, 7:53 AM, "Stig Venaas" <stig@venaas.com> wrote: Hi I only meant that with AMT and Wi-Fi, the experience should hopefully be equivalent to regular native multicast. I agree you often need FEC to protect against loss, and also in some cases some kind of retransmission or unicast assistance. Assuming there is no loss in the core until an AMT relay is reached, then I suppose an AMT specific solution could work, but I would like a generic solution that can work for native multicast. I don't remember exactly what was done for reliable multicast in the IETF now. Anyone remember better than me? I remember proposals including how to do retransmissions. Stig On Wed, Nov 8, 2017 at 1:50 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote: > On Tue, 7 Nov 2017, Stig Venaas wrote: > >> Hi >> >> I don't think AMT needs to be more reliable than regular multicast. If > > > Deploying multicast for linear TV without FEC is an operational nightmare > that never stops. You need to constantly measure customer experience > (preferrably in the STBs, all of this with proprietary solutions afaik) or > try to measure it in your network (using expensive equipement). > > I recommend all my enemies to deploy this at large scale. > >> you are concerned about Wi-Fi, then by using AMT to the device, the >> packets will be unicast packets, so the regular Wi-Fi handling of unicast >> packets (including retransmissions) should be sufficient. Do you need >> additional retransmissions? > > > Unicast will be far superior to multicast over wifi, but it's probably still > not enough to give a good enough customer experience without FEC. > > FEC in this aspect means the application deteriorates gracefully under > packet loss, by smearing out infomation across packets and degrading quality > without for instance magenta squares gliding along the screen until the next > full screen update (that might be a second into the future (or more)). > > This "FEC" can also be (as some have done), by the devices receiving > multicast packets and then requesting (via unicast) from a server of some > kind, to get the packets it lost. The few solutions available when I was > involved in this before, were all proprietary. They were also used to speed > up channel changes by providing full screen update immediately, before same > information came via the multicast stream. > > In packet networks, packets are lost. It's a fact. They're designed to > behave this way. From what I can see, there are two ways to handle this. > Either we come up with a standards based retransmission mechanism for > multicast streams that anyone can use, or we punt the problem to the > application layer, and let them figure it out. We need to be perfectly clear > to everybody what our choice is. > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ MBONED mailing list MBONED@ietf.org https://www.ietf.org/mailman/listinfo/mboned
- [MBONED] deprecating MSDP Dale W. Carder
- Re: [MBONED] deprecating MSDP Leonard Giuliano
- Re: [MBONED] deprecating MSDP Hitoshi Asaeda
- Re: [MBONED] deprecating MSDP Dino Farinacci
- Re: [MBONED] deprecating MSDP Rob Evans
- [MBONED] (*,G) to (S,G) translation (Re: deprecat… Hitoshi Asaeda
- Re: [MBONED] (*,G) to (S,G) translation (Re: depr… Dino Farinacci
- Re: [MBONED] deprecating MSDP Tim Chown
- Re: [MBONED] deprecating MSDP Leonard Giuliano
- Re: [MBONED] deprecating MSDP Leonard Giuliano
- Re: [MBONED] deprecating MSDP John Kristoff
- Re: [MBONED] deprecating MSDP Tim Chown
- Re: [MBONED] deprecating MSDP John Kristoff
- Re: [MBONED] deprecating MSDP Toerless Eckert
- Re: [MBONED] deprecating MSDP Leonard Giuliano
- Re: [MBONED] deprecating MSDP Manfredi, Albert E
- Re: [MBONED] deprecating MSDP Mikael Abrahamsson
- Re: [MBONED] deprecating MSDP Dino Farinacci
- Re: [MBONED] deprecating MSDP Toerless Eckert
- Re: [MBONED] deprecating MSDP Toerless Eckert
- Re: [MBONED] deprecating MSDP Toerless Eckert
- Re: [MBONED] deprecating MSDP Mikael Abrahamsson
- Re: [MBONED] deprecating MSDP Leonard Giuliano
- Re: [MBONED] deprecating MSDP Mikael Abrahamsson
- Re: [MBONED] deprecating MSDP Manfredi, Albert E
- [MBONED] deploying internet-wide multicast (RE: d… Mikael Abrahamsson
- Re: [MBONED] deprecating MSDP Leonard Giuliano
- Re: [MBONED] deprecating MSDP Manfredi, Albert E
- Re: [MBONED] deprecating MSDP Toerless Eckert
- Re: [MBONED] deprecating MSDP Mikael Abrahamsson
- Re: [MBONED] deprecating MSDP Toerless Eckert
- Re: [MBONED] deprecating MSDP Mikael Abrahamsson
- Re: [MBONED] deprecating MSDP Toerless Eckert
- Re: [MBONED] deprecating MSDP Mikael Abrahamsson
- Re: [MBONED] deprecating MSDP Mikael Abrahamsson
- Re: [MBONED] deprecating MSDP Toerless Eckert
- Re: [MBONED] deploying internet-wide multicast (R… Stig Venaas
- Re: [MBONED] deprecating MSDP Stig Venaas
- Re: [MBONED] deprecating MSDP zhang.zheng
- Re: [MBONED] deploying internet-wide multicast (R… Toerless Eckert
- Re: [MBONED] deprecating MSDP Toerless Eckert
- Re: [MBONED] deprecating MSDP Toerless Eckert
- Re: [MBONED] deploying internet-wide multicast (R… Mikael Abrahamsson
- Re: [MBONED] deprecating MSDP Leonard Giuliano
- Re: [MBONED] deploying internet-wide multicast (R… Stig Venaas
- Re: [MBONED] deploying internet-wide multicast (R… Holland, Jake
- Re: [MBONED] deploying internet-wide multicast (R… Dino Farinacci
- Re: [MBONED] deploying internet-wide multicast (R… Greg Shepherd
- Re: [MBONED] deploying internet-wide multicast (R… Toerless Eckert
- Re: [MBONED] deploying internet-wide multicast (R… Morten V. Pedersen
- Re: [MBONED] deploying internet-wide multicast (R… Toerless Eckert
- Re: [MBONED] deploying internet-wide multicast (R… Holland, Jake
- Re: [MBONED] deploying internet-wide multicast (R… Toerless Eckert
- Re: [MBONED] deploying internet-wide multicast (R… Manfredi, Albert E
- Re: [MBONED] deploying internet-wide multicast (R… Toerless Eckert
- Re: [MBONED] deploying internet-wide multicast (R… Manfredi, Albert E
- Re: [MBONED] deploying internet-wide multicast (R… Mikael Abrahamsson
- Re: [MBONED] deploying internet-wide multicast (R… Toerless Eckert
- Re: [MBONED] deploying internet-wide multicast (R… Toerless Eckert
- Re: [MBONED] deploying internet-wide multicast (R… Mikael Abrahamsson