[irtf-discuss] Notes/minutes for London IRTFOPEN meeting

Below and in the interim proceedings you'll find a report of the IETF 101
IRTFOPEN meeting.

Thank you to Mat Ford for the fine raw notes, and thanks again to the ANRP
speakers especially, Vaspol and Mojgan!

If there are any corrections for the minutes, please let me know

Allison

-----------------------

IRTFOPEN Meeting, Weds March 21, 2018
=================================

Scribe: Mat Ford, with minor updates by AM

## 9:30 Opening remarks, IRTF Chair

Slides:
https://datatracker.ietf.org/meeting/101/materials/slides-101-irtfopen-allison-mankin-irtf-chair-opening-remarks-01

 Note Well, Photography Policy
 Review of IRTF Mission - NO standardization in IRTF
 PAN Proposed RG supported move to RG
 GAIA-themed tech plenary
 All groups meeting
 ANRW2018 - submission deadline is April 20 - please submit!

## 9:40 Vision for a QIRG: Quantum Internet Research Group
Rod van Meter (RvM), Stephanie Wehner (unable to join the meeting)

Slides:
https://datatracker.ietf.org/meeting/101/materials/slides-101-irtfopen-van-meter-and-wehner-vision-for-a-quantum-internet-research-group-02

3 main use cases for quantum networks: distributed cryptographic networks,
sensor networks and distributed computation (blind computation)
more than 50 startups in the quantum industry now, many created in the last
year, none known to be working on quantum repeaters yet
mailing list is open: https://www.irtf.org/mailman/listinfo/qirg

Hirotaka Nakajima: According to your slides, p.9 there is no IP or TCP but
your figures say that only bottom layer is quantum network - it seems like
there is new different network we are trying to create - will we create a
new network? if quantum network prevents use of IP etc. harder to connect
and communicate between classical and quantum network - is there work to
achieve this communication?

RvM: Those are good questions. We are going to have to have a new physical
layer, no getting around that - there is work going on to allow that to
multiplex with standard TCP/IP traffic in the same fiber - has been
demonstrated experimentally. All of the other functions shown on slide 9
are all new protocols but they also need a way to exchange their classical
messages reliably - what is a request from an application to the network
itself? How does it make that request, what does it contain, what are the
semantics, etc. The coloured boxes on the slide will largely ride on top of
TCP in my opinion - it's building a large distributed application on top.

Wes Hardaker: Originally thinking this was early, but then decided that I
was wrong and that we want to get this right from the start. So timing is
perfect - excited to see this go forward. Could add security requirements
for what will be layered on top in particular with respect to privacy
concerns. Example: satellite is perfect case of store-and-forward mechanism
- quantum routers have similar property. There are a number of things that
need to be considered about technology needed above that, properties of
protocols used on top of this whole system that can be relaxed because you
have quantum, or that you still need.

RvM: yes, sign that man up!

Shota Nagoyama: Comment - organisation of terminology - some people start
to propose different terminology for concepts - so there is need for a
place for open discussion - different terminology is emerging - IRTF would
be good place to try to forge some consensus. We should carefully discuss
abstraction of entanglement and interaction of classical networks with
entanglement. One benefit of talking about quantum networking in IRTF is
that we can involve network engineering people in the discussion which will
be important from an early stage.

RvM: I agree with all of your comments. I have had heartburn when
physicists use a term from classical engineering that causes confusion.
E.g. multiplexing, repeater. Guarantess about the security of various
approaches cause headdesk moments for those that have experience of the
differences between theory and practical reality when running networks.
Interaction with practitioners will be key to healthy, extensible, robust,
long-lived quantum Internet architecture.

Mariko Kobayashi: I'm not familiar with this area, but comment to community
- quantum computing is clearly important to future of networking - but not
many people with expertise here - how will we get IETF engineers involved
in the discussion, and similarly how should we bring quantum folks here?

RvM: The plan starts with the creation of a Research Group. We create the
forum. I'm pleased to hear earlier comment that maybe now is the right time
to prevent physicists from going down the wrong path. There are already
hundreds of researchers around the world working on this. The two workshops
that I mentioned are one way, there are lots of people already working on
the technologies - goal is to bring them together with the people who
really understand how networks behave.

Mariko: I think you need to encourage more people unfamiliar with this to
get involved.

Allison: Hopefully having the presentation in this meeting is a good start
- the mailing list is open so join in (
https://www.irtf.org/mailman/listinfo/qirg)

Applied Network Research Prize talks
====================================

## 10:10 Performance Characterization of a Commercial Streaming Video
Service
Mojgan Ghasemi (MG)

Slides:
https://datatracker.ietf.org/meeting/101/materials/slides-101-irtfopen-mojgan-ghasemi-performance-characterization-of-a-commercial-streaming-video-service-anrp-00

Stuart Cheshire: Thanks for interesting presentation. Most of traffic on
Internet is streaming video so very important to get right. You mentioned
client download stack latencies, working for Apple that's an area I'm
familiar with. Pipeline delays, client side download stack - as far as I
know there is no networking API on Windows, Linux or Mac that will just sit
on data for no reason and not deliver it. I think this is a consequence of
the APIs in-order delivery of data. You could have a 2 second queue on a
cable modem link, you lose one packet, fast retransmit fills in the packet
really fast, but it's at the back of a 2 second queue, data piles up in
kernel, sockets API can't deliver it, and then one missing packet arrives
and suddenly 200KB arrives all at once. So you see plateaus of no data,
then suddenly a spike because of one missing packet arrived.

MG: I agree. We have more data in the paper that confirms what you're
saying. Usually the API. Problem is player is sitting on a black box - it's
probably the way that data delivery is being handled - we have a footnote
in the paper that says we can only guess about what is happening.

SC: You have a good point. With current APIs you can't tell if there is
just no data or if there is lots of data with one missing packet.

Wes Hardaker: Excellent presentation, having said that, you killed my dream
- I dreamed that users would be able to discover new things but your
caching results indicate that video streaming services are motivated to bin
people into popular titles. They won't give you suggestions of things
sideways, they'll suggest things that everybody else is watching too.
They're not likely to suggest unpopoular material. This is sad.

MG: That's true, I think everybody does that.

Tsu Hong: Is this intended for video-on-demand or livestreaming or both?

MG: Dataset that I discussed is from Video on demand, but same systems are
used for CDN and are applicable to livestreaming events as well.

Melinda Shore relaying Simon Pietro Romano from Jabber: Has all this been
carried out with Flash clients, is there an updated study with MPEG-DASH
clients?

MG: I think we mentioned that in the paper.

## 11:00 Vroom: Accelerating the Mobile Web with Server-Aided Dependency
Resolution
Vaspol Ruamviboonsuk (VR)

Slides:
https://datatracker.ietf.org/meeting/101/materials/slides-101-irtfopen-vaspol-ruamviboonsuk-vroom-vroom-accelerating-the-mobile-web-with-server-aided-dependency-resolution-anrp-01

Alex Mayrhofer: Nice to see someone working on this in practice. Do you
employ any mechanism that avoids pushing the same resource twice to the
same client? I'm not talking about link preload, but pushing CSS on each
page for example.

VR: In this work I'm not doing anything to prevent that because we have
control of what we push so we ensure we're not pushing it twice.

No Name Given (mea culpa by Chair for not asking): Can you give us an idea
about how many of these mobile-optimised pages how many URLs are in a page
and how many actually change the page and are not just spyware? Are people
optimising for mobile giving up some of the overhead of non-mobile pages?
Are there 100s of URLs, or dozens?

VR: At least 50 URLs, for news and sports sites it's in the order of
hundreds.

Followup: So this means that people serving these sites could stop
operating in this way they could solve this problem themselves?

VR: Yes, I agree.

Zhen Cao: In your dataset do you have any data reflecting how many websites
use domain-sharding technologies?

VR: Most of them are using domain sharding when we performed our
experiments. Hopefully http2 will render that less common but a year or two
ago when I was doing this research it was common.

ZC: You assert underutilised CPU/network, but domain-sharding offers some
parallelism.

VR: Separate issue - browsers are designed with one main process that is
doing all these tasks - sometimes browser will have to wait for some
processing to happen to utilise the network, so domain-sharding doesn't
help in that case.

Yoav Weiss: I'm participating in priority preload work that you mentioned.
Would be interesting to integrate concept of javascript scheduler into
browser resource scheduling process. In that context, the red line you
showed that separated critical from non-critical resources - is there a way
a browser can identify these in a deterministic way? Trigger non-critical
loads in ideal time seems like a complex problem - how did you solve that?

VR: I don't have a good answer off the top of  my head. It's very tricky -
we are not claiming that we can detect all resources - javascript that has
some kind of randomised token means we can't discover those resources. From
the browser's perspective it's hard to know what all the resources needed
will be.

YW: I'm sure we'll still need processing, but determining in real time what
are most critical resources would be helpful. Defining the red line in real
time would be extremely interesting.

VR: I agree.

Alan Cheilek: Did you do any research into how many unnecessary resources
were downloaded? e.g. high-DPI images pushed and then not used

VR: Unfortunately I didn't study that. One thing to note is that all our
experiments start from the assumption that none of these sites are doing
any push, so what we did in our work was to study best case scenario.

Alan Cheilek: I guess another way to ask the question would be, 'How many
additional bytes were downloaded using Vroom than not using Vroom?'

VR: There would be more bytes from the signalling, but I don't know the
exact answer but would expect it to be small compared to the whole size of
the page.

Alan Cheilek: Seems like if we had a better way to organise html and
javascript resources then server-side processing along these lines wouldn't
be necessary. But now I'm tilting at windmills, so I'll stop.

Matt Mathis: It feels like this is optimising at the wrong layer - content
providers should be optimising better ahead of time and they're not for
some reason - what are the incentives here? domain sharding seems to work
the same way that excessive choice somehow underlying this is inappropriate
incentives, did you look at any of the causes of why things are done in
these inefficient ways? It feels like you're optimising something that
somebody else optimised towards a different goal.

VR: I guess optimisation can have side-effects on other performance - we
should be more inclusive.

MM: I think they were the ones being uninclusive.

Tsu Hong: Why do you use nexus 6 and not some newer phone?

VR: At the time this was the best phone we could get (2 years ago).

## 11:50 Any other discussion/questions

Dave Plonka - Could we spend a few minutes talking about how ANRW was
formed? Thanks to ISOC and ACM for helping to put this together. Can you
tell us how the committee was selected, what was their reach, diversity
goals? I see there's an invited talk from someone on the program committee
- that's unusual.

AM: Neither of the program chairs is here, it's a better question for them.
The invited talk question is interesting - there is variation as to whether
this is a reasonable thing to do or not - I think the reason they seeded
the invited talks so early was to give a strong representation of some of
the topics and range. It's possible the program committee could grow some
more so if you were to raise a question about its composition to the
program chairs it would be timely.

DP: I love the way that ANRW is diffferent and I love having it during the
IETF week, I'm just looking to improve. If inviting already published
stuff, we already do that for ANRP. We should raise the bar for ourselves
and think some more about how we select the committee, but the timelines
are good.  Mostly I'm happy with it.

AM: There is a hope that there will be lots of submissions of the short
talks (the ones not previously published). Folks here, please encourage
research colleagues to submit. I had had in mind that perhaps the
committtee should expand. Regarding continuing versus once a year, we are
thinking slowly about some of those kinds of ideas. We're looking to
increase the amount of Applied Networking Research on the agenda, many
times there's a big gap between academic research and what we could build
and deploy on the real-world Internet so we're looking to enhance these
relationships in every way we can.

DP: One carrot for coming to ANRW versus say IMC is that talks will be
recorded - we're building a very valuable library of awesome presentations
talks. Students like to list these on their webpages for example. I'm also
asking IMC to start doing this.

AM: You are one of the two chairs of maprg research group - measurement and
analysis for protocols - so this is a very parallel case to the ANRW...

DP: Yes it's a measurement focussed subset of what could be at ANRW. The
ANRW program committee looks really good (about 1/3 women, about 1/3
academics who already participate in IETF) but we should tell people how
this is constructed.

AM: Agree. Thanks all for coming, see you on the mailing list. Will also be
reporting to the plenary tonight.

Meeting adjourned.