Subject: Re: [Webpush] New Version Notification for draft-begen-webpush-dash-reqs-00.txt

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 30 Oct 2014 16:45:00 +0000

On Oct 30, 2014 6:02 PM, Martin Thomson <[email-masked]> wrote:
>
> On 30 October 2014 08:50, Ali C. Begen (abegen) <[email-masked]> wrote:
> > I asked the WG chairs to give us some time to present these core experiments, mention about our requirements and seek some guidance from the WG.
>
> I think that this work is more appropriate for the HTTP working group.

Could be but there is an incoming liaison from the mpeg to the webpush WG so I think a short discussion will be useful.

Also for clarification we are not making or asking for any changes in the http protocol.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 30 Oct 2014 10:36:04 -0700

On 30 October 2014 09:45, Ali C. Begen (abegen) <[email-masked]> wrote:
> Could be but there is an incoming liaison from the mpeg to the webpush WG so
> I think a short discussion will be useful.

How about we start that discussion here.  How do you think that this
is relevant to the work in this working group?

---

From: Shida Schubert <[email-masked]>
Date: Thu, 30 Oct 2014 11:17:31 -0700

I agree with Martin in that we should start the discussion on the mailing list.

If we see that we can benefit from F2F time, then we can allocate some time at the meeting.  

Shida as co-chair

On Oct 30, 2014, at 10:36 AM, Martin Thomson <[email-masked]> wrote:

> _______________________________________________
> Webpush mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webpush

---

From: JR Conlin <[email-masked]>
Date: Thu, 30 Oct 2014 14:26:12 -0700

If I understand the core of the proposal correctly, this is a request to
layer a media content delivery and control system on top of WebPush.

I'm going to start by saying that I'm a fan of simplicity. I believe
that things should be minimal and play nice with other things.

It's certainly possible to embed streaming rich media content and
control into WebPush. It's also equally possible to layer the X windows
protocol into WebPush for remote terminal display and control. I'm not
really sure that WebPush should be the vector for that sort of thing.

I think it's certainly possible for WebPush to help initiate a more
efficient, dedicated protocol exchange between parties, possibly even
using the same common HTTP2 (or like) carrier channel, but I don't
believe it really behooves anyone to add more layers onto a fairly
complex exchange as is.

I'm also not quite certain that WebPush could address some of the larger
issues that a media content delivery and control system might have (e.g.
broadcast control of multiple recipients, metricing, multi-end secure
key dispersal, etc.)

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 30 Oct 2014 23:58:04 +0000

________________________________________
From: Webpush [[email-masked]] on behalf of JR Conlin [[email-masked]]
Sent: Thursday, October 30, 2014 5:26 PM
To: [email-masked]
Subject: Re: [Webpush] New Version Notification for draft-begen-webpush-dash-reqs-00.txt

acbegen: First of all, I apologize for the lack of depth of information on the DASH stuff in the draft. The MPEG meeting was last week where it was decided to submit this draft to this WG (and send an official liaison to this WG, too). Now, I assume you are familiar with how media is carried over HTTP today with several not-so-different technologies like microsoft smooth, apple hls, adobe zeri, netflix, etc. These technologies (and also DASH) already use HTTP as it is to distribute content (both live and on-demand) in a "pull-based" fashion. A streaming client asks for a piece of content and the server sends it. Quite simple, widely deployed and works fine. Yet, thru core experiments, the DASH subgroup at MPEG is investigating for new features/solutions that might enhance the streaming service. For example, low-latency live streaming is quite desirable and for that we are looking into websockets and push features of http/2. A lightweight messaging plane between the servers (and possibly other devices on the network) and streaming clients seems also quite desirable to solve a number of issues in existing deployments. It is not strictly a control system per se. We will define the messages that will be carried over this plane but now we are trying to choose the best protocol to use on this plane. Hence, the interest in the webpush protocol.

acbegen: No disagreement here.

acbegen: If it turns out the protocol solution you are trying to develop here will not fit our needs, then we will naturally use something else. I don't think you or anyone else on this list should reach a yes/no conclusion right away. I looked at the list archives and the wg charter, and I could not be sure about the ultimate application target for the outcome of this WG, but I have to say that given a large portion (if not huge) of the HTTP traffic is already DASH-like media, I believe this WG should at least understand the problems we have and maybe take our requirements into account.

acbegen: Don't worry about those details. As I said we are already in the process of defining what messages/info could/should/would be carried over the messaging plane using a web push protocol. That work belongs to MPEG not to this WG.

I hope this clarifies the intent of the draft.

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 30 Oct 2014 23:59:21 +0000

I replied to JR's email first and I hope it has enough meat to start the discussion. Please follow up as you see fit.
________________________________________
From: Martin Thomson [[email-masked]]
Sent: Thursday, October 30, 2014 1:36 PM
To: Ali C. Begen (abegen)
Cc: Kevin Streeter; [email-masked]; Franck Denoual; Imed Bouazizi
Subject: Re: [Webpush] New Version Notification for draft-begen-webpush-dash-reqs-00.txt

---

From: Martin Thomson <[email-masked]>
Date: Fri, 31 Oct 2014 08:59:22 -0700

On 30 October 2014 16:58, Ali C. Begen (abegen) <[email-masked]> wrote:
> A lightweight messaging plane between the servers (and possibly other devices on the network) and streaming clients seems also quite desirable to solve a number of issues in existing deployments.

If you already have a connection to the server, is there any reason
you couldn't use HTTP to exchange these messages?

Web Push is intended to provide a lightweight substitute for constant
connectivity. This is intended to ensure availability for devices that
need to conserve scarce resources, like a phone needs to conserve
power for its radio.

Sending messages over Web Push when the target of those requests is
already connected to you is not appropriate.  Performance worse than
sending packets directly, and it is a far more expensive method of
exchanging data.