Re: [GGIE] Where from here?

["Leslie Daigle" <[e-mail]>]

Responding to just a few of your points, in-line, and otherwise waiting 
to hear further thoughts from others:

On 30 Nov 2018, at 15:16, Holland, Jake wrote:

> 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

I think your comment above is addressing my comment:
[I had written]
> 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.

But I don’t think you’ve addressed my implied point:  it doesn’t 
much matter what *we* think, it matters what the IESG thinks if there is 
to be a WG.  And, I’d appreciate others’ thoughts if there is the 
belief that an OPS working group for anything other than an IETF 
protocol is something that the IESG is likely to be supportive of.



> 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?


What’s your definition of success?  For the purposes of what we’ve 
been trying to do within the IETF (get existing players to have more 
awareness of each other and generally raise awareness of the work that 
exists already), I don’t think that’s true.

For broader industry growth and coherence, I think you’re right.  But 
I don’t think it’s an IETF(-only) activity to pursue.  At least, not 
yet.


Again — not a complete follow up to your note, but I’m going to go 
back to listening for a bit.

Leslie.

> 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]>


> _______________________________________________
> GGIE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ggie