Subject: [Qirg] Fwd: [irtf-discuss] Notes/minutes for London IRTFOPEN meeting

From: Rodney Van Meter <[email-masked]>
Date: Wed, 11 Apr 2018 09:26:13 +0900

For those of you who aren’t familiar with the way IETF & IRTF work, this venture started with a presentation at the IRTF Open meeting in London in March. The notes from that, focusing on the Q&A, were just sent to the IRTF Discussion list.

> Begin forwarded message:
> 
> From: Allison Mankin <[email-masked]>
> Subject: [irtf-discuss] Notes/minutes for London IRTFOPEN meeting
> Date: April 11, 2018 at 7:50:54 AM GMT+9
> To: [email-masked], "Internet Research Steering Group ([email-masked])" <[email-masked]>
> 
> 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 <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 <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 <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 <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 <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 <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.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>

---

From: Az Mankin <[email-masked]>
Date: Wed, 11 Apr 2018 15:45:05 +0100

And here's a link to the video of the talk given at IRTFOPEN:

https://www.youtube.com/watch?v=WICdZ6qOmRo#t=0h10m20s

On Wed, Apr 11, 2018 at 1:26 AM, Rodney Van Meter <[email-masked]>
wrote:

> For those of you who aren’t familiar with the way IETF & IRTF work, this
> venture started with a presentation at the IRTF Open meeting in London in
> March. The notes from that, focusing on the Q&A, were just sent to the IRTF
> Discussion list.
>
> Begin forwarded message:
>
> *From: *Allison Mankin <[email-masked]>
> *Subject: **[irtf-discuss] Notes/minutes for London IRTFOPEN meeting*
> *Date: *April 11, 2018 at 7:50:54 AM GMT+9
> *To: [email-masked], "Internet Research Steering Group (
> [email-masked])" <[email-masked]>
>
> Slides: https://datatracker.ietf.org/meeting/101/materials/slides-
> 101-irtfopen-allison-mankin-irtf-chair-opening-remarks-01
> <https://datatracker.ietf..org/meeting/101/materials/slides-101-irtfopen-allison-mankin-irtf-chair-opening-remarks-01>
>
> 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.
>
> 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.
>
> 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)
>
>
> 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: 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?
>
> 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?
>
> 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.
>
> 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.
>
> 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.
>
> _______________________________________________
> Qirg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/qirg
>
>