Hi, Lars, Thank you, and Jana, for tugging on this.
On Thu, Oct 8, 2020, 01:13 Lars Eggert <[email protected]> wrote: > 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. > We really do need to trim back the tree of potential paths forward, even if the interim meeting can't converge on a single path forward. This goal seems sufficient to help the chairs flesh out an agenda. Other things could be on the agenda, of course. Best, Spencer 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 >
