Re: [MBONED] deploying internet-wide multicast (RE: deprecating MSDP)

[Toerless Eckert <[e-mail]>]

On Wed, Nov 08, 2017 at 10:00:00PM +0000, Holland, Jake wrote:
> +1 on hoping for RTP. And maybe we should cc payload.
> 
> I still don???t know enough about RTP or video coding to be certain I???m making sense, but from what I understand, the adaptive RTP solutions today have sender back off under congestion? It seems to me that would need to change for multicast.

No, you do not slow down the sender.

RTP schemes are just like ABR schemes, eg: multiple bitrates availalable,
receiver "joins" to the bitrate(s) it can receive without congestion.

Key difference to ABR schemes is that you can docode after usually
every packet you receive as opposed to ABR where you can decode only after
the whole block is received (2 secs or longer usually). And with RTP
you can much easier work in content aware redundancy schemes. E.g.: in ABR
you need 100% reliability and therefore use retransmission like NORM/FLUTE
to get all pakets in a block. In RTP you can decide frame-by-frame
whether a loss of data from that frame results in a visual degradation
that demands retransmisssion or whethre you'd rather not retransmit but
for example interpolate it. And the encoding of different frames can be
done to support such more flexible & dynamic quality vs. delay vs.
burstyness/retransmission choices.

> I think the Scalable Video Coding that???s part of VP9 (and optional in h.264) is a really promising approach for doing ABR with multicast RTP. In theory, if it were supported and the sender were sending the right way, in response to congestion indications like loss or CE markings, the client could leave (S,G)s corresponding to higher-resolution enhancement layers and still keep the lower-resolution video layers at a bandwidth level that works well for his path. If you got it to work well, maybe the purple squares or video skips could be at more like the frequency of the player buffering you???d get in unicast, and mostly only happening when network conditions change.

No idea if VP9 is introducing something new or if this is all just what
we had in MPEG SVC for a decade. I'd hope that they simply copied the
best options and made the IPR free. I'd be surprised though if they had
specific support for some of the low-latency variable loss support details
that commercial MPEG solutions have built.

> As I understand it, that???s not possible today, but if I???m reading the latest diffs correctly, support for the concept has been added to the vp9 payload draft, so it might become possible if somebody takes up the work?
> https://tools.ietf.org/html/draft-ietf-payload-vp9-04#section-4.5
> 
> I???m not sure about the reliability, because it seems like you???d still get those purple squares on lost packets, but you could at least reduce the incidence of lost packets due to congestion, and maybe that would make it possible for a little bit of FEC to keep up under any reasonably stable network. But I imagine that improving the reliability will be another project of its own, and there???s a bad tradeoff with the delay. But maybe it???s possible to get reliability with less delay than reliable unicast segmented video has to pay.

In general you have frames that are used as references by other frames and
those that are not. Loss in the latter ones can to a good extend be
compensated for by interpolation between the next and prior frame if
you allow for a few frames playout delay and have enogh CPU to do
motion interpolation. Reference frames on the other hand should more
likely be protected by enough FEC so they almosst never have loss. Else
you need low-latency retransmissions like from a nearby cache on the
gateway (assuming last-hop loss on wifi).

> This is precisely what I mean by ???there???s work to do before normal implementations of open standards can do this???. To me it looks probably achievable but not imminent.

Cheers
    Toerless

> -Jake
> 
> On 11/8/17, 1:07 PM, "Toerless Eckert" <[e-mail]> wrote:
> 
> The CableLabs solution does not carry IP multicast across the home network.
> It makes the home gateway an HTTP proxy where IP multicast + NORM is used
> on the uplink to retrieve the content in a scalable fashion between content
> server and gateways - via a fairly well controlled SP network only.
> The amount of loss that NORM has to cope with should be very small, but of
> course it needs to be 0 to support the use case, thats why you still need a
> reliable transport protocol.
> 
> I was always hoping that there was still a chance to build
> the transport solution for rate adaptive video on top of RTP because it
> would create a lot less ABR problems like overhead and delay (talk about sports
> and delay). I thought there are some solution architectures on the mobile side
> that may use RTP, but not quite sure. I've helped build solutions that
> do use rate adaptive RTP and i thought that worked very well (low latency et.al.).
> 
> For walled garden IPTV use cases, the cablelabs approach should be quite attractive 
> you just need to eliminate all the cable specific pieces you don't need, which
> shouldn't be difficult. You just won't get a good score on the soccer-goal-delay rankings. 
> 
> If we're talking federated or OTT video which is what AMT was looking to support,
> then this cablelabs approach direction would rather be an alternative: Just put
> an HTTP cache on your home-gateway  to enable local retransmissions from cache
> on the gateway and rely on TCP (HTTP(s)) from gateway to client. No multicast
> needed.
> 
> Cheers
>     Toerless
> 
> On Wed, Nov 08, 2017 at 06:22:23PM +0000, Holland, Jake wrote:
> > 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" <[e-mail]> 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 <[e-mail]> 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: [e-mail]
> > 
> > _______________________________________________
> > MBONED mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mboned
> > 
> > 
> > _______________________________________________
> > MBONED mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mboned
> 
> -- 
> ---
> [e-mail]
> 
> 

-- 
---
[e-mail]