[04:50:03] RAJARAM Gnanajeyaraman joins the room
[04:50:03] Christian Huitema joins the room
[04:50:03] Yoshifumi Nishida joins the room
[04:50:03] Jonathan Morton joins the room
[04:50:03] Kevin Yang joins the room
[04:50:03] Tobia Castaldi joins the room
[04:50:03] Carles Gomez joins the room
[04:50:03] Jiao Kang joins the room
[04:50:03] Daniel Havey joins the room
[04:50:38] Dmitri Tikhonov joins the room
[04:50:52] Michael Tüxen leaves the room
[04:51:21] Yoshifumi Nishida leaves the room
[04:51:26] Michael Tüxen joins the room
[04:51:26] Yoshifumi Nishida joins the room
[04:51:42] Yoshifumi Nishida leaves the room
[04:52:14] Michael Scharf joins the room
[04:52:24] Yoshifumi Nishida joins the room
[04:52:54] <Yoshifumi Nishida> OK.
[04:52:58] Peter Heist joins the room
[04:53:02] <Yoshifumi Nishida> I'm having audio issue for now
[04:53:13] Richard Scheffenegger joins the room
[04:53:22] Hirochika Asai joins the room
[04:53:32] Mihail Yanev joins the room
[04:53:33] Mihail Yanev leaves the room
[04:53:33] Frode Kileng joins the room
[04:53:42] Mihail Yanev joins the room
[04:53:48] Markus Amend joins the room
[04:53:50] Tommy Pauly joins the room
[04:53:51] Mihail Yanev leaves the room
[04:53:55] Mihail Yanev joins the room
[04:53:58] Matt Mathis joins the room
[04:54:12] frodek joins the room
[04:54:36] <Tobia Castaldi> Hi Yoshifumi, I'm writing in private to try to help you
[04:55:23] Yoshifumi Nishida leaves the room
[04:55:28] Yoshifumi Nishida joins the room
[04:56:05] Martin Duke joins the room
[04:56:29] Yoshifumi Nishida leaves the room
[04:56:33] Yoshifumi Nishida joins the room
[04:56:40] DanielHavey joins the room
[04:56:58] Bob Briscoe joins the room
[04:57:15] Lars Eggert joins the room
[04:57:15] Wesley Eddy joins the room
[04:57:39] Jie Yang joins the room
[04:58:11] Chi-Jiun Su joins the room
[04:58:15] Yoshifumi Nishida leaves the room
[04:58:15] Mohit Tahiliani joins the room
[04:58:18] Mirja Kühlewind joins the room
[04:58:18] Yoshifumi Nishida joins the room
[04:58:18] Mohamed Boucadair joins the room
[04:58:25] alex-meetecho joins the room
[04:58:35] <Tobia Castaldi> yes, I cn
[04:58:40] RAJARAM Gnanajeyaraman leaves the room
[04:58:51] RAJARAM Gnanajeyaraman joins the room
[04:59:09] <Mirja Kühlewind> Good morning, good night, and everything in between...!
[04:59:21] Neal Cardwell joins the room
[04:59:34] Gorry Fairhurst joins the room
[04:59:48] Praveen Balasubramanian joins the room
[05:00:02] Kazuaki Ueda joins the room
[05:01:02] Andrew McGregor joins the room
[05:01:06] Marcus Ihlar joins the room
[05:01:19] Olivier Bonaventure joins the room
[05:01:34] Stephen McQuistin joins the room
[05:01:35] Eric Kinnear joins the room
[05:02:22] Stephen McQuistin leaves the room
[05:02:28] Stephen McQuistin joins the room
[05:02:28] Hannu Flinck joins the room
[05:02:33] Yuchung Cheng joins the room
[05:02:54] <Michael Scharf> Hi all, I do monitor the meetecho chat. In case you want me to relay something on the mic, please clearly mark that (e.g. by "mic:"). Thx Michael
[05:03:18] Dmitri Tikhonov leaves the room
[05:03:29] Mahesh Jethanandani joins the room
[05:03:29] Jana Iyengar joins the room
[05:03:45] Greg White joins the room
[05:03:58] Dmitri Tikhonov joins the room
[05:04:10] Kazuho Oku joins the room
[05:04:12] Jana Iyengar leaves the room
[05:04:17] Jana Iyengar joins the room
[05:04:53] Vidhi Goel joins the room
[05:05:06] Sergey Fomin joins the room
[05:05:09] Philip Eardley joins the room
[05:05:53] Dirk Hugo joins the room
[05:07:55] Nicolas Kuhn joins the room
[05:08:10] Dirk Hugo leaves the room
[05:08:28] Jana Iyengar leaves the room
[05:08:33] Jana Iyengar joins the room
[05:08:40] Nicolas Kuhn leaves the room
[05:08:45] Nicolas Kuhn joins the room
[05:09:31] Ingemar Johansson joins the room
[05:10:40] Jana Iyengar leaves the room
[05:11:13] <Mirja Kühlewind> @Lars I'm also implementing cubic at the moment but I ended up rather following the paper than the RFC...
[05:11:56] <Martin Duke> I agree with Lars
[05:12:08] <Lars Eggert> mirja, the paper is known to be outdated
[05:12:32] <Vidhi Goel> The paper is somewhat outdated and has a few differences from the RFC
[05:12:35] <Mirja Kühlewind> I looked at both but the paper was easier to follow to start with
[05:12:56] <Mirja Kühlewind> would be good to highlight these differences
[05:13:12] Christian Huitema_*** joins the room
[05:13:16] <Lars Eggert> good idea! could you open an issue so we don't forget?
[05:13:27] Sergey Fomin leaves the room
[05:13:27] Joakim Misund joins the room
[05:13:30] Sergey Fomin joins the room
[05:13:41] Dirk Hugo joins the room
[05:13:53] <Vidhi Goel> cubic_beta is different (0.8 vs 0.7)
[05:13:58] Nicolas Kuhn leaves the room
[05:14:04] Nicolas Kuhn joins the room
[05:14:09] <Christian Huitema_***> I followed the RFC, and then I did not. I could not get the "Reno mode" to work as specced.
[05:14:10] Jana Iyengar joins the room
[05:14:23] Dirk Hugo leaves the room
[05:14:24] <Mirja Kühlewind> where is the repo?
[05:14:28] Dirk Hugo joins the room
[05:14:31] Hiroyuki Goto joins the room
[05:14:32] Igor Lubashev joins the room
[05:14:42] Igor Lubashev leaves the room
[05:14:43] <Jonathan Morton> https://github.com/NTAP/rfc8312bis/issues
[05:14:47] Igor Lubashev joins the room
[05:15:03] Nicolas Kuhn leaves the room
[05:15:08] Nicolas Kuhn joins the room
[05:15:44] <Vidhi Goel> @Christian, which part of TCP friendly are you referring to? Is itW_est(t) = W_max*beta_cubic +
                   [3*(1-beta_cubic)/(1+beta_cubic)] * (t/RTT)
[05:15:46] <Mirja Kühlewind> thx
[05:16:06] Jasmine Magallanes joins the room
[05:20:30] Yunchul Choi joins the room
[05:21:17] Yunchul Choi leaves the room
[05:21:22] Yunchul Choi joins the room
[05:22:43] Igor Lubashev leaves the room
[05:22:48] Yuchung Cheng leaves the room
[05:22:53] Yuchung Cheng joins the room
[05:22:58] Lohith Bellad joins the room
[05:23:12] Yuchung Cheng leaves the room
[05:23:16] Yuchung Cheng joins the room
[05:23:42] Yuchung Cheng leaves the room
[05:23:46] Yuchung Cheng joins the room
[05:25:02] Lohith Bellad leaves the room
[05:26:08] Mohit Tahiliani leaves the room
[05:26:14] Mohit Tahiliani joins the room
[05:27:25] Hiroyuki Goto leaves the room
[05:28:04] Dirk Hugo leaves the room
[05:28:16] Dirk Hugo joins the room
[05:30:30] Dirk Hugo leaves the room
[05:30:54] Dirk Hugo joins the room
[05:31:12] ihlar joins the room
[05:34:31] <Mohit Tahiliani> @Lars - would it be a good idea to add details about how CUBIC responds to ECN?
[05:35:08] Meetecho joins the room
[05:36:00] <Vidhi Goel> It already exists. Check https://tools.ietf.org/html/rfc8312#section-4.5
[05:37:00] <Mohit Tahiliani> I'm asking this because during the hackathon last week, we implemented ECN support in ns-3 CUBIC model. While doing so, we had to see how Linux does it and we found RFC does not mention these details.
[05:37:28] <Mohit Tahiliani> Here are the details from the hackathon: https://docs.google.com/document/d/1QiDqBo94wKr1eptTFe6xAB0RWWlwYOy8VLOWrpVAie8/edit
[05:38:21] <Mohit Tahiliani> @Vidhi - yes, the RFC mentions about ECN but it is not how Linux does it
[05:39:28] <Vidhi Goel> On receiving ECE marking, the congestion controller needs to reduce congestion window and enter CA. Does linux not do that?
[05:40:36] <Mohit Tahiliani> No, it enters a state called CWR state and follows PRR
[05:40:36] Kannan Jayaraman joins the room
[05:41:45] Michael Tüxen leaves the room
[05:41:45] <Vidhi Goel> Could you file an issue?
[05:41:55] <Mohit Tahiliani> Sure
[05:41:59] <Mohit Tahiliani> Thanks!
[05:42:15] Michael Tüxen joins the room
[05:42:32] <Jonathan Morton> CWR state should proceed to CA when PRR concludes, by setting ssthresh below cwnd
[05:43:15] Lv Yunping joins the room
[05:43:29] <Mohit Tahiliani> Yes Jonathan, that's right. It does not directly go to CA
[05:43:36] <Matt Mathis> Without CWR&amp;PRR you would have a 1/2 RTT of silence.
[05:44:05] <Mirja Kühlewind> but that's not specific to use of ECN, no?
[05:44:10] Mahesh Jethanandani leaves the room
[05:44:30] <Matt Mathis> They take exactly one RTT to accomplish the same thing.  Correct
[05:44:37] SungHoon Seo joins the room
[05:44:51] <Mohit Tahiliani> CWR state is specific to ECN, PRR not
[05:45:27] <Jonathan Morton> I think CWR state logically replaces Fast Recovery
[05:46:02] Qiufang Ma joins the room
[05:46:48] <Gorry Fairhurst> No audio from Jana.
[05:47:43] Yunchul Choi leaves the room
[05:48:03] Lv Yunping leaves the room
[05:48:08] Lv Yunping joins the room
[05:49:23] <Gorry Fairhurst> I think we SHOULD add text around the widely used "normal" options.
[05:49:25] <Bob Briscoe> Yes, lots
[05:49:53] <Bob Briscoe> Search RFCs authored by Sally Floyd ;)
[05:52:23] <Jana Iyengar> Bob -- Sally's RFC (I'll find it) is not particularly useful
[05:52:47] <Martin Duke> Could we put some sort of minimum bound on the congestion control, e.g. MUST NOT [starve] RFC5681, with something more precise substituted for "starve"?
[05:52:58] <Jonathan Morton> +1
[05:53:14] Michael Tüxen leaves the room
[05:53:19] Michael Tüxen joins the room
[05:53:26] <Jana Iyengar> Sally's RFC: https://tools.ietf.org/html/rfc2914
[05:53:46] <Jana Iyengar> Unfortunately, I don't find this particularly helpful
[05:54:14] <Jana Iyengar> However, @Martin Duke: This is something that ICCRG could take on
[05:54:51] <Michael Scharf> draft-fairhurst-tsvwg-cc would perhaps be useful in that discussion, if there was consensus on it
[05:54:56] <Martin Duke> Without saying it solves all the implementer's problem, maybe a reference to 2914is better than saying "congestion control" with no additional context or explanation
[05:55:34] <Martin Duke> and also easy for Wes to insert without delaying WGLC
[05:55:37] <Bob Briscoe> I wasn't recommending we refer to these RFCs about what makes a good CC. I was just answering Martin's  question about whether there are any.
[05:55:53] <Wesley Eddy> many experimental algos fallback to Reno-like behavior, or Reno-friendly rates, so this might also be good to point out in the guidance
[05:55:56] <Gorry Fairhurst> I'll repost that ID ... it was however a summary of what the RFCs say... which might not be the same, still could be a starting poiny
[05:56:53] <Bob Briscoe> I think the previous suggestion of an IETF-approved CC sounded good (the precise suggestion was actually a stds track CC, but I'm not so sure about that - again, thinking of the challenged device scenario, an experimental CC would seem OK).
[05:57:31] <Bob Briscoe> Bear in mind we're talking here about what CCs have to be implemented, not which one(s) are used.
[05:57:38] Min Kang joins the room
[05:57:58] Mohamed Boucadair leaves the room
[05:58:03] Mohamed Boucadair joins the room
[05:58:19] Kannan Jayaraman leaves the room
[05:58:19] Qiufang Ma leaves the room
[05:58:22] <Praveen Balasubramanian> how about SHOULD implement some CC and recommend 5681 as the default choice
[05:58:23] Dragana Damjanovic joins the room
[05:58:25] Qiufang Ma joins the room
[05:58:34] <Gorry Fairhurst> :-)
[05:58:47] Jiao Kang leaves the room
[05:58:47] <Matt Mathis> Only SHOULD?
[05:58:56] <Gorry Fairhurst> MUST?
[05:58:57] Jiao Kang joins the room
[05:59:04] <Michael Scharf> It should be a MAY ;-)
[05:59:05] <Praveen Balasubramanian> agreed MUST is better
[05:59:17] Markus Amend leaves the room
[05:59:23] <Vidhi Goel> I don't think 5681 should be default choice. Is there a reason to provide any reference to 5681 at all?
[05:59:25] Markus Amend joins the room
[05:59:46] Lv Yunping leaves the room
[06:00:01] <Praveen Balasubramanian> even QUIC has chosen to document reno as default!
[06:00:20] <Martin Duke> do we have any other standards track CCs?
[06:00:23] <Wesley Eddy> so ... how about MUST implement CC, SHOULD be a CC published as an RFC, 5681 is one example
[06:00:38] Lv Yunping joins the room
[06:01:06] Markus Amend leaves the room
[06:01:06] <Gorry Fairhurst> I  could live with that.
[06:01:09] Markus Amend joins the room
[06:01:09] <Richard Scheffenegger> technical mic issues.
[06:01:33] Markus Amend leaves the room
[06:01:46] <Praveen Balasubramanian> that text would work for me
[06:01:55] <Richard Scheffenegger> For SYN: Use option with length to include no data, to minimize option length. In SYN we are limited in available space...
[06:02:00] Markus Amend joins the room
[06:02:09] Markus Amend leaves the room
[06:02:14] Markus Amend joins the room
[06:02:33] <Jana Iyengar> @Praveen: QUIC hasn't documented Reno as default; it is an example
[06:02:59] <Jana Iyengar> "This document specifies a sender-side congestion controller for QUIC similar to TCP NewReno ([RFC6582]).
The signals QUIC provides for congestion control are generic and are designed to support different sender-side algorithms. A sender can unilaterally choose a different algorithm to use, such as Cubic ([RFC8312]).
If a sender uses a different controller than that specified in this document, the chosen controller MUST conform to the congestion control guidelines specified in Section 3.1 of [RFC8085]."
[06:03:04] Jie Yang leaves the room
[06:03:11] Jie Yang joins the room
[06:03:22] <Jana Iyengar> Section 3.1 of 8085 points to 2914
[06:03:38] <Vidhi Goel> Reg. Wes's text, a small modification "can it be how about MUST implement CC, 5681 is one example" (I don't know why it has to be published RFC)
[06:03:51] <Praveen Balasubramanian> @Jana fair, just citing 5681 as example should suffice
[06:03:54] <Jonathan Morton> IMHO, using length field to distinguish announce option from data-bearing option is logical, and I'm surprised it is not used more often already
[06:04:16] <Jana Iyengar> I agree with Vidhi, though pointing to something like 2914 is helpful to loosely define congestion control.
[06:04:48] <Gorry Fairhurst> I am less sure this is the correct approach for TCP.
[06:04:53] <Praveen Balasubramanian> I like "published as RFC" because it forces the work to be brought to IETF and be peer reviewed and have multiple implementations and measurement
[06:05:23] <Carles Gomez> @Richard, Jonathan: thanks! This is very useful.
[06:05:35] <Bob Briscoe> Regards the present talk, see useful ideas for backward compatibility with existing timestamp in draft-https://tools.ietf.org/html/draft-scheffenegger-tcpm-timestamp-negotiation-05
[06:05:46] <Michael Scharf> TSV-ART has repeatedly forced other WGs to have pretty strong language regarding congestion control (e.g., for UDP encaps). I am not sure if we can get away with *do some CC* in TCP.
[06:05:48] <Richard Scheffenegger> @Praveen: I like that text proposal
[06:06:15] <Jana Iyengar> @Michael: Yes, and they all end up pointing to 8085 and 2914
[06:06:24] <Gorry Fairhurst> And TCP is a core spec, that many protocols rely upon, for TCP this work needs to be brought in the IETF. I think we need to require CC, and RFC
[06:06:35] <Wesley Eddy> "SHOULD" allows freedom to do something else, with good justification
[06:08:08] <Martin Duke> Scharf +1
[06:08:26] <Jana Iyengar> I'll note again: If we want consistency with documents, then let's leave the text as is. If we want to reflect reality, we need to acknowledge that people build and deploy CCs in TCP unilaterally, and without IETF "approval". What I would like to encourage is IETF/IRTF engagement.
[06:09:16] <Michael Scharf> RFC 8085 indeed points to 2914. But 8085 also points to best current practice in TCP... So, the exact wording for TCP does matter...
[06:09:48] <Jana Iyengar> We should absolutely require CC. I'm saying that the algorithm does not need to be required. This is not about interop, and there's no enforcement.
[06:10:22] Hiroyuki Goto joins the room
[06:10:27] <Matt Mathis> +1 to Jana
[06:10:27] Olivier Bonaventure leaves the room
[06:10:33] Olivier Bonaventure joins the room
[06:10:34] <Mohit Tahiliani> +1 Jana
[06:10:40] Anna Brunstrom joins the room
[06:11:33] <Bob Briscoe> Enforcement isn't completely absent
[06:11:34] <Jana Iyengar> I agree that the status quo is not satisfactory in terms of what we have in our documents right now. That doesn't mean we lose sight of reality in trying to be consistent with what we have as IETF documents.
[06:11:46] <Gorry Fairhurst> -1 Jana: The decision can be made for QUIC, but the case for TCP is different.
[06:11:51] <Jonathan Morton> RFC-8311: Effective congestion control is REQUIRED
[06:12:04] <Mirja Kühlewind> If we want to say more, I think we also need a warning that new CC needs to be deployed carefully
[06:13:17] <Jana Iyengar> Agreed Mirja.
[06:13:49] <Jana Iyengar> @Gorry -- I don't see why the decision is different. From the network's point of view, QUIC and TCP congestion are the same.
[06:13:57] <Jana Iyengar> (similar, anyway)
[06:15:09] Hiroyuki Goto leaves the room
[06:16:23] RAJARAM Gnanajeyaraman leaves the room
[06:19:41] <Mirja Kühlewind> +1 to Praveen; delayed ack should be separate
[06:20:24] Dragana Damjanovic leaves the room
[06:20:46] <Gorry Fairhurst> There are many specs built on TCP by a variety of groups. The update we speak about is intended as full-standard. TCP has formed a conservative spec that forms a reference - that's one reason why the UDP Guidelines points to that. There will be other CCs out there, and that's fine - some will be problematic, some better.
[06:20:55] <Praveen Balasubramanian> middlebox issues is the other problem here but I suppose we are left in no worse state than today
[06:21:22] Pyung-Soo Kim joins the room
[06:22:10] Pyung-Soo Kim leaves the room
[06:22:15] Pyung-Soo Kim joins the room
[06:23:01] Pyung-Soo Kim leaves the room
[06:23:17] <Martin Duke> @Jana I believe the correct sequence is (1) Implement a CC (2) SIGCOMM paper (3) come to IETF to ratify what you already deployed at scale
[06:23:58] Pyung-Soo Kim joins the room
[06:24:53] <Michael Scharf> In any case, I expect that RTG area will very carefully review the normative language in 793bis. They may look for "revenge" ;-) And, BTW, the norm in RTG area is PS specification, like elsewhere in the IETF.
[06:25:27] <Jana Iyengar> Are we worried that we might force RTG area to enter the 20th century?
[06:26:06] <Michael Scharf> No, RTG may force us to eat our own dog food.
[06:26:34] Dirk Hugo leaves the room
[06:27:00] Dirk Hugo joins the room
[06:28:34] Dirk Hugo leaves the room
[06:28:42] Dirk Hugo joins the room
[06:28:53] <Matt Mathis> For many of us, not open licence is a showstopper for even reading a draft
[06:28:56] <Jonathan Morton> NewReno is the established baseline CC, CUBIC is a widely deployed alternative, a small fixed cwnd may be a valid alternative for very constrained systems…
[06:31:58] <Jonathan Morton> Jiao may want to move her microphone a little further from her mouth
[06:32:46] David Schinazi joins the room
[06:32:46] Nick Banks joins the room
[06:35:03] Neal Cardwell leaves the room
[06:37:45] Dirk Hugo leaves the room
[06:38:00] Dirk Hugo joins the room
[06:38:47] Dirk Hugo leaves the room
[06:38:52] Dirk Hugo joins the room
[06:38:56] Hiroyuki Goto joins the room
[06:39:12] Dirk Hugo leaves the room
[06:39:15] Dirk Hugo joins the room
[06:40:45] Qiufang Ma leaves the room
[06:42:16] Hannu Flinck leaves the room
[06:42:46] Hannu Flinck joins the room
[06:43:41] Pyung-Soo Kim leaves the room
[06:43:46] Sergey Fomin leaves the room
[06:43:53] Zhen Cao joins the room
[06:43:56] Sergey Fomin joins the room
[06:44:55] <Mirja Kühlewind> +1 to updating and PS!
[06:45:21] <Mohit Tahiliani> +1 for the PS
[06:45:22] Joakim Misund_461 joins the room
[06:45:37] <Mohit Tahiliani> ns-3 also uses PRR as the default recovery algorithm
[06:45:48] Igor Lubashev joins the room
[06:45:51] Kevin Yang leaves the room
[06:46:33] <Lars Eggert> +1 to do this, and as PS
[06:46:56] Dirk Hugo leaves the room
[06:47:25] Dirk Hugo joins the room
[06:48:12] Dirk Hugo leaves the room
[06:48:35] Dirk Hugo joins the room
[06:49:22] Dirk Hugo leaves the room
[06:49:27] Pyung-Soo Kim joins the room
[06:49:50] Pyung-Soo Kim leaves the room
[06:49:53] Dirk Hugo joins the room
[06:50:56] Dirk Hugo leaves the room
[06:50:59] Dirk Hugo joins the room
[06:51:18] <Mirja Kühlewind> pacing helps but still whenever you lose multiple packets in a round PRR is still the right thing to do
[06:52:21] <Mirja Kühlewind> but PRR depends on how rate reduction is implemented
[06:52:40] <Jana Iyengar> Mirja -- pacing takes care of that situation
[06:53:02] <Jana Iyengar> You can lose all packets, and pacing will result in the next round going out at the reduced rate
[06:53:22] <Mirja Kühlewind> depending on how you implement rate reduction
[06:53:48] <Mirja Kühlewind> if you only send out one packet per ACK pacing will not help
[06:55:13] <Jonathan Morton> what about if you get a bunch of acks due to link aggregation?
[06:55:26] <Jonathan Morton> that's common with wifi and cable
[06:55:49] <Mirja Kühlewind> in that case you should pace (but that independent of PRR)
[06:56:08] <Matt Mathis> A single SACK can indicate that pipe is much smaller, so it can trigger multiple segments, even in recovery with PRR.  They should be paced  
[06:56:27] Mohit Tahiliani leaves the room
[06:56:28] <Jonathan Morton> right, so PRR releases one packet per ack to the pacer, and the pacer takes care of spacing them
[06:57:05] Dirk Hugo leaves the room
[06:57:24] <Mirja Kühlewind> the packet conservation principle "releases" one packet per ACK. PRR aims to compensate this in case of loss
[06:57:33] <Matt Mathis> No
[06:57:57] <Matt Mathis> Not per ack, per segment delivered, including as indicated by sack blocks
[06:58:06] <Mirja Kühlewind> yes
[06:58:53] <Jana Iyengar> How does this work if the entity terminating the TCP connection and entity terminating the TLS session are different?
[06:59:29] <Jana Iyengar> HTTP CONNECT proxies, for example
[06:59:30] <Mirja Kühlewind> How does TLS depend on this?
[07:00:31] <Mirja Kühlewind> Ah sorry you are not taking about PRR ;-)
[07:00:36] <Jana Iyengar> TLS doesn't depend on this, but you're negotiating TCP options with an entity that is not going to be terminating your TCP connection
[07:00:50] <Jana Iyengar> Yes :-) I'm talking about this proposal
[07:01:41] <Mirja Kühlewind> Is that the same "problem" that QUIC has?
[07:01:49] Sergey Fomin leaves the room
[07:02:08] <Martin Duke> no, because you can't terminate the QUIC separately from TLS
[07:03:04] Dirk Hugo joins the room
[07:03:06] Hiroyuki Goto leaves the room
[07:03:58] <Mirja Kühlewind> Ah the question if this can lead to ambiguity...
[07:04:50] Matt Mathis leaves the room
[07:05:21] Dirk Hugo leaves the room
[07:05:36] Stephen McQuistin leaves the room
[07:05:43] Dirk Hugo joins the room
[07:06:56] <Mirja Kühlewind> interesting!
[07:06:59] Kazuhisa Matsuzono joins the room
[07:07:09] Nicolas Kuhn leaves the room
[07:07:12] Dmitri Tikhonov leaves the room
[07:07:13] <Jana Iyengar> remote code execution!
[07:07:14] Markus Amend leaves the room
[07:07:15] Lars Eggert leaves the room
[07:07:16] Nick Banks leaves the room
[07:07:16] Marcus Ihlar leaves the room
[07:07:16] Yuchung Cheng leaves the room
[07:07:17] Lv Yunping leaves the room
[07:07:17] Chi-Jiun Su leaves the room
[07:07:17] Jiao Kang leaves the room
[07:07:17] Zhen Cao leaves the room
[07:07:18] Richard Scheffenegger leaves the room
[07:07:18] Tommy Pauly leaves the room
[07:07:19] Mihail Yanev leaves the room
[07:07:19] Eric Kinnear leaves the room
[07:07:20] Andrew McGregor leaves the room
[07:07:21] Mohamed Boucadair leaves the room
[07:07:22] Carles Gomez leaves the room
[07:07:23] Joakim Misund_461 leaves the room
[07:07:23] Wesley Eddy leaves the room
[07:07:24] Igor Lubashev leaves the room
[07:07:25] Peter Heist leaves the room
[07:07:28] <Mirja Kühlewind> thanks all! Bye!
[07:07:29] Greg White leaves the room
[07:07:29] Hirochika Asai leaves the room
[07:07:31] Jana Iyengar leaves the room
[07:07:32] Dirk Hugo leaves the room
[07:07:35] David Schinazi leaves the room
[07:07:35] Ingemar Johansson leaves the room
[07:07:38] Kazuho Oku leaves the room
[07:07:39] Yoshifumi Nishida leaves the room
[07:07:39] Hannu Flinck leaves the room
[07:07:39] SungHoon Seo leaves the room
[07:07:39] Michael Scharf leaves the room
[07:07:39] Martin Duke leaves the room
[07:07:39] Bob Briscoe leaves the room
[07:07:39] Christian Huitema leaves the room
[07:07:39] Kazuhisa Matsuzono leaves the room
[07:07:39] Tobia Castaldi leaves the room
[07:07:39] Jie Yang leaves the room
[07:07:39] Daniel Havey leaves the room
[07:07:39] Vidhi Goel leaves the room
[07:07:39] Mirja Kühlewind leaves the room
[07:07:39] Philip Eardley leaves the room
[07:07:39] Jonathan Morton leaves the room
[07:07:39] Jasmine Magallanes leaves the room
[07:07:39] Michael Tüxen leaves the room
[07:07:39] Kazuaki Ueda leaves the room
[07:07:39] Gorry Fairhurst leaves the room
[07:07:39] Olivier Bonaventure leaves the room
[07:07:39] Anna Brunstrom leaves the room
[07:07:39] Frode Kileng leaves the room
[07:07:39] Min Kang leaves the room
[07:07:40] Praveen Balasubramanian leaves the room
[07:16:51] Christian Huitema_*** is now known as Christian Huitema
[07:19:29] Meetecho leaves the room
[07:24:15] frodek leaves the room
[07:32:05] DanielHavey leaves the room
[07:52:41] alex-meetecho leaves the room
[08:59:43] Joakim Misund leaves the room
[10:30:11] ihlar leaves the room
[10:51:42] ihlar joins the room
[11:40:53] Christian Huitema leaves the room
[11:57:30] ihlar joins the room
[11:58:15] ihlar leaves the room
[16:01:03] ihlar joins the room
[16:17:53] ihlar leaves the room
[18:13:21] halfshot joins the room
[18:13:27] halfshot leaves the room
[18:23:53] undefined joins the room
[21:10:03] ihlar leaves the room