Re: [GGIE] Where from here?

["Holland, Jake" <[e-mail]>]

I like Colin’s suggestion of an ops working group.

Even though I’d rather see it be broader than a specific protocol, an
ops venue for reporting on operational issues around video and media on
the internet seems like it covers what we’ve been doing. I would hope
it’s also appropriate for presenting on experimental protocols, as long
as there’s an implementation and maybe a deployment. (I wouldn’t mind
seeing operational experiences from a walled-garden deployment of ggie,
for instance. I don’t support assigning an address block at this time,
but I’m curious to hear about how it scales and where the challenges
are, if there’s anybody trying to run it for real. Likewise with any kind
of multicast video someone is willing to talk about, or other approaches
to deep caching.)

That said, I’m still not convinced that a research group is wrong. I’ll
link below to a set of papers I’ve encountered over the last few years.
These papers are trying to solve internet problems for video
applications, and were not presented at IETF/IRTF.

Would they have been presented if there were an appropriate research
group? I don’t know, but I would have liked to see them there. They look
like research to me, even though they are targeted for immediate
deployment, and actively deployed in some cases. How many more such are
there? Which are best? Which ones might be useful to try to standardize?
I don’t know, and we have no broad internet expert review, because they
weren’t presented at IRTF. But they are clearly about interactions
between video and the internet, mostly related to some form of Adaptive
Bit Rate.

However, Ali had some good counterpoints that I haven’t seen addressed,
namely:
1. media touches on so many other organizations, many of which are not
compatible with working with the ietf or irtf rules. Without their
inclusion, success is hard to reach
2. Certain folks in the ietf community are interested in media but then
many media related people are not even aware of the ietf or irtf.  How
do we go about them?
3. that might be too strong, but yes (in response to: “topics
specific to media over internet (aside from RTP)
are not worth trying to address at IETF/IRTF?”)

I trust Ali’s judgement on this better than my own. I think he knows the
video industry better, and I haven’t seen counter-arguments. I haven’t
visited most of the various video groups, and I don’t have an answer to
these, especially #1 and #3.  (Although I think forming an official
research or working group and perhaps establishing some liaison
relationships would be a good step toward addressing point #2.)

I would love for someone to expand on these counter-points. Perhaps
these objections are a correct prediction for why an internet media
research or ops group will fail to be useful. Perhaps if I understood
these objections more fully, I would not waste everybody’s time.

But right now, I’m in favor of a research group as a first preference,
and an ops group as a second preference, and I’m happy to follow
along with consensus supporting either. Maybe to help with making
it happen.

I’m currently against “not worthwhile”, but I would like to understand
in better detail if there are reasons that might convince me.

Cheers,
Jake

The papers I promised:
[1] QAPIB (2014 Krishnamoorthi et al): Quality-adaptive Prefetching for
Interactive Branched Video
http://www.ida.liu.se/~nikca89/papers/mm14.pdf
[2] “Adaptation Algorithm” (2012 Miller et.al.): heuristics combining
buffer occupancy and bandwidth measurements
https://pdfs.semanticscholar.org/44bc/d20a481c00f5b92d55405f9bf70a12f99b8f.pdf
[3] BOLA (2016 Spiteri et.al.): change bitrate according to video buffer
occupancy--can join bitrates above measured bandwidth in variants besides
BOLA-O:
https://people.cs.umass.edu/~ramesh/Site/HOME_files/Bola.pdf
[4] BBA (2014 Huang et.al):
http://yuba.stanford.edu/~huangty/bba_report.pdf
http://tiny-tera.stanford.edu/~nickm/papers/ty-thesis.pdf
[5] PID/PIA (2017 Qin et al.): control-theory-based approach that ends up
similar to BBA?
https://www.cs.indiana.edu/~fengqian/paper/pid_infocom17.pdf
[6] ELASTIC (2013 Cicco et al.): paced reading off the socket to avoid
leaving idle time between chunks (which keeps TCP rwnd-bound, which avoids
going into slow start, which helps because it avoid getting several RTTs
per block after idle with an artificially low bandwidth signal)
https://pdfs.semanticscholar.org/558f/5f8ea046e95af97b4f7b546a1b9e32a7d30d.pdf?_ga=2.259735242.1751904480.1509168921-745757155.1509168921
[7] PANDA (2013 Li et al): fetch chunks in big enough batches so reno can
stabilize and you can get a better bandwidth reading
https://arxiv.org/pdf/1305.0510.pdf
[8] FESTIVE (2012 Jiang et al.): randomize chunk request times to avoid
synchronization between players and get fairer sharing
http://conferences.sigcomm.org/co-next/2012/eproceedings/conext/p97.pdf
[9] Fuzzy (2017 Linh et al): moving average bandwidth with stabilization
based on entropy
http://www.mdpi.com/1099-4300/19/9/477/pdf


From: Leslie Daigle <[e-mail]>
Date: 2018-11-30 at 09:26
To: "[e-mail]" <[e-mail]>
Subject: [GGIE] Where from here?


I want to pick up the thread about whether or not we should see about establishing some more formal group at the IETF. Also, see the bottom of this message for a history of the meetings we’ve had at the IETF, and attendance levels. The table probably looks like crap in e-mail; better formatting and more detail (including links to notes!) at https://yana.techark.org/vig-at-ietf/<https://urldefense.proofpoint.com/v2/url?u=https-3A__yana.techark.org_vig-2Dat-2Dietf_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=K8gAusSDoDIEEqhiq9HOhjtEHOn-3GqGDjorxeLAAYw&s=kvmcnnfB3d6YewXpBhW-Twq2Vk--Zst4gmQmwgoL09E&e=> .

Now, a couple of words about what we’ve been trying to achieve with these “video interest group” meetings.

One of the things we discovered, while working on the GGIE proposal at the IETF, was that there are a lot of people who are doing video-related work, with and to Internet protocols at the IETF. Nonetheless, many people are not aware of each other’s efforts, if for no other reason than that the work winds up in different Areas — transport, security, art, and even routing.

It has seemed to us that bringing these people together so that there is greater awareness — of each other, of the work that’s being done — would help both the work being done, and the IETF as a whole. It can be pretty daunting to try to get one particular thing done in the IETF, and knowing that there are others interested in the outcome can be helpful. Also, the more we can raise awareness of general video interests at the IETF, the more likely the IETF is to recognize the need to address them.

We’ve kept on using the GGIE list for coordination simply because it spans those areas, and has 64 members who have, at some time, been interested in/working on video at the IETF.

So, that’s where we’ve been. Where from here? If the IETF had a concept of “interest group”, the way other organizations do, we’d pursue that. As it doesn’t, we can look at Working Groups or Research Groups.

Working Groups are generally chartered to achieve specific technical outcomes — whether it’s developing a standard or taking care of maintenance tasks on a deployed standard (like the v6ops and dnsop groups that someone mentioned). However, we haven’t been talking about an individual protocol/technology, and we don’t fit in a single area.

There are also some “dispatch”-style WGs, typically one per Area — if we had a Video Area at the IETF, we could easily set that up :-). That would suppose there is enough video work at the IETF (beyond the applications and realtime work currently being done) to have multiple working groups. Are we there, yet?

So then we come to the other obvious candidate — a research group. It would address the operational needs of finding actual time on the IETF schedule, and it would open us up to broader participation. On the one hand, it seems to fit because we are trying to bring together people to talk about a broad swath of advanced issues related to video. On the other — we’re explicitly not talking about research. We’ve been talking about stuff that is current protocol work, and active product and service development. To do a research group properly, we should actively solicit more input on the longer term work that’s being researched, related to video. While that certainly could be interesting, I’m not sure I see how it feeds back into increasing IETF awareness of video-requirements in protocol work.

The alternative, that we’ve been pursuing, is to keep doing the informal thing, until we have some kind of critical mass of IETF participants doing video work to have a clearer idea of whether there is a WG, or an Area, or something else that would better support the ongoing discussion.

Here’s our history at the IETF:

Video Interest Group IETF 103 (Bangkok) 16

Video Interest Group IETF 102 (Montreal) 19
Video Interest Group IETF 101 (London) 19

Video Content Handling side meeting IETF 100 (Singapore) 16

Streaming Video bar bof IETF 99 (Prague) 20

Streaming Video bar bof IETF 98 (Chicago) 62
GGIE at DISPATCH WG IETF 96 (Berlin) N/A
GGIE Bar BoF IETF 94 (Yokohama) 14

Again — more detail, better formatting, at https://yana.techark.org/vig-at-ietf/<https://urldefense.proofpoint.com/v2/url?u=https-3A__yana.techark.org_vig-2Dat-2Dietf_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=K8gAusSDoDIEEqhiq9HOhjtEHOn-3GqGDjorxeLAAYw&s=kvmcnnfB3d6YewXpBhW-Twq2Vk--Zst4gmQmwgoL09E&e=> .

Thoughts?

Leslie.

--

________________________________

Leslie Daigle
Principal, ThinkingCat Enterprises

[e-mail]<mailto:[e-mail]>