Multicast streaming video client

Phillip Hallam-Baker <> Thu, 26 January 2017 00:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1AF3612943A for <>; Wed, 25 Jan 2017 16:49:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Xyi1JbXCPGFd for <>; Wed, 25 Jan 2017 16:49:10 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5A363129442 for <>; Wed, 25 Jan 2017 16:49:10 -0800 (PST)
Received: by with SMTP id r126so51047215wmr.0 for <>; Wed, 25 Jan 2017 16:49:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=mXMgT5bJWsYZDK6tsg6v/ll7gxf/abn1QRlg98DEKi8=; b=hnnfjbh4IZmjWuqc87nF1oHRYn8bl1ephxrvE4NMlRbzE1TFcm9ltkOh2RcCu89gPs hb9f2PEkN1zO5TRqFU8GUC6ZW7jUnI9h6MGQfEsd8XDot8DBpLhED0CIrWGfS9GbLRa4 rJ8YVg3hbWGkpryvLRXi/Rvgw4uSvTckHQiLilXIeBNuyOEa7WRaiwQTVswwiDNwC9Ea +fO7K7I0piH6YkVKncWmmobOuNordPCGu7hOly3GBadZ3j5Q48w41HRsLtX2xp1hdHHk 44+fjG4VHV1Jlw1lViQs3qkzX6u/RaH0KjMSwpb5UhaEaC9VKk3BhZxGlaqGFITVu4P2 uJzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=mXMgT5bJWsYZDK6tsg6v/ll7gxf/abn1QRlg98DEKi8=; b=U62Tc4deuCBiGtv1vhCBXySnaa0jrOyDlvri74wCUE5hGILafvrL9ih2EA0VmeH0Us dKXQ6ZvtYV/CPqbiYCZ1uqPNqPJrCs0ab3Uo0hmltns5rksxblqoCBbi9Re835IaIx/K k8CbBpfFnfMCB7YoB2C947g0Imd/mFGfLpoFRWfA8uOtF0t2Znhlj2SFkZr7S6rroFAp X94AqeFtJpdufSGKNQ2vM3NaycZBa82Eox4nGXi1ou/J04Idc4ajUZPom6XBoOuh+H8M F6V7wGfcNGgqhIx0CeCI5nsm7xS2xZt1g/KLcwcEFmdLipolg8HjrmcCVADjNSqqjJzm Adgg==
X-Gm-Message-State: AIkVDXK/4zHoWYGlL0k4GFQHxJQJ76cCknLRS6mA7xXP7nE7Ba1lft2FpzoFpdcVQ3CbpLxJ7hqwvEwnsGy0Tw==
X-Received: by with SMTP id e5mr104237wrc.133.1485391748602; Wed, 25 Jan 2017 16:49:08 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 25 Jan 2017 16:49:07 -0800 (PST)
From: Phillip Hallam-Baker <>
Date: Wed, 25 Jan 2017 19:49:07 -0500
X-Google-Sender-Auth: 8gjxcBxS_sLRyVJPTH8ahtLcKDM
Message-ID: <>
Subject: Multicast streaming video client
To: IETF Discussion Mailing List <>
Content-Type: multipart/alternative; boundary=94eb2c1b4e608721370546f4b74e
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Jan 2017 00:49:12 -0000

​One of the big complaints coming back from the inauguration weekend was
that the vast crowds ​were unable to see the podium or even the rebroadcast
sites. Which has me thinking that there is an application protocol need to
be filled here. If everyone at the demonstration connected up over LTE or
WiFi using our existing protocols, the bandwidth would be sucked dry. Same
thing happens in convention spaces (and IETF meetings).

I won't be able to get to work on this till 2018 at the earliest and even
then, I can probably add most value on the crypto side. Some of the results
I have been getting with proxy re-encryption are very promising. We could
get to a genuinely end to end encrypted Web some time.

Now quite possibly, there is something of the sort already built. In fact I
proposed something of the sort several years ago but that specific need was
overtaken by events.

Imagine that there is a video streaming client that takes its content
stream from a combination of a multicast channel and a unicast channel. At
a coarse level, the client receives packets over the multicast link and
requests retransmission over the unicast.

It is going to be a little trickier than that of course because if you have
a stream and one packet drops at the upstream side, the source is going to
get slammed if every client asks for retransmit at once. So there has to be
some research on how to avoid slamming the source. Perhaps there is a
random element in requesting retransmit. Given that we are talking video
here, we can accept latencies of quite a few frames.

It seems to me that the logical starting point for standardizing such a
protocol would be the QUIC RFCs. But as I point out above, this would
require a research effort before standardization.

Just a thought.