Hi, On 2020-10-6, at 10:21, Lars Eggert <[email protected]> wrote: > we decided to take up Ian's suggestion to schedule a virtual interim meeting > to discuss the multipath topic. To find a suitable time before the next IETF > meeting, please fill out the Doodle at > > https://doodle.com/poll/iqmap34cszi4qub4 > > by the end of Thursday, Oct 8. We'll pick a slot on Friday, Oct 9 and > announce it.
reminder to please state your preferences by the end of today. > On each day, there are two four-hour slots that I think are workable, given > our participant distribution. We received feedback that four hours are maybe more than needed, and a long slot like this makes scheduling somewhat more difficult. Speaking as one chair - but without having discussed this to great lengths with my co-chairs - the goal for the interim is to try and come to consensus on what to do about the multipath work item our current charter includes. A 2h slot is likely OK for this. We'll identify a 4h slots based on the Doodle poll and will try to select a 2h window within that slot that further maximizes attendance. Multipath was included in our initial charter, because it was being investigated for Google QUIC, which was the main input to our work. As can be observed by discussions over the past year or so - and especially during the last few weeks - whether the QUIC WG or the IETF should work on multipath support for QUIC, and on what time line - is a contentious topic. Many options have been expressed in this discussion so far, ranging from "remove the charter item and BOF the topic" to "adopt draft-deconinck and start the work now" and other options in between. The purpose of the interim is to provide a higher-bandwidth venue for this discussion, in the hopes that some ways forward emerge that might reach consensus. Personally, I believe that is essential that any complex engineering on QUIC, such as the addition of multipath, is motivated by the needs of large-scale deployments and driven by engineers that are in a position to feed back experiences and data from such deployments into the design process in a timely manner. This is how the WG managed to develop the existing QUIC specifications in a relatively short amount of time (given the changes we made to the initial QUIC design). It would be unfortunate if we gave up this proven model of design and engineering. Thanks, Lars
signature.asc
Description: Message signed with OpenPGP
