[{"author": "Sean Turner", "text": ":mask:<br/>", "time": "2022-03-21T13:31:19Z"}, {"author": "Cullen Jennings", "text": "FWIW ... one of the mics has lots of hiss in this room <br/>", "time": "2022-03-21T13:32:54Z"}, {"author": "Tommy Pauly", "text": "I thought that was a snake :snake:<br/>", "time": "2022-03-21T13:33:40Z"}, {"author": "David Schinazi", "text": "Do you know which one Cullen?<br/>", "time": "2022-03-21T13:33:45Z"}, {"author": "Cullen Jennings", "text": "nope - sorry <br/>", "time": "2022-03-21T13:33:59Z"}, {"author": "David Schinazi", "text": "No worries<br/>", "time": "2022-03-21T13:34:24Z"}, {"author": "afrind@jabb3r.org", "text": "I can jabber scribe<br/>", "time": "2022-03-21T13:35:00Z"}, {"author": "Martin Thomson", "text": "there are no open issues on the h3 datagram spec<br/>", "time": "2022-03-21T13:42:38Z"}, {"author": "Tommy Pauly", "text": "Yeah, last call sounds fine<br/>", "time": "2022-03-21T13:42:44Z"}, {"author": "Martin Thomson", "text": "it seems like it is time for WGLC, yes<br/>", "time": "2022-03-21T13:42:51Z"}, {"author": "Sean Turner", "text": "+1 to wglc<br/>", "time": "2022-03-21T13:42:59Z"}, {"author": "Cullen Jennings", "text": "+1<br/>", "time": "2022-03-21T13:43:02Z"}, {"author": "afrind@jabb3r.org", "text": "+1<br/>", "time": "2022-03-21T13:43:05Z"}, {"author": "Martin Thomson", "text": "I read through just a few minutes ago and I found a typo.&nbsp;&nbsp;That's it.<br/>", "time": "2022-03-21T13:44:53Z"}, {"author": "Martin Thomson", "text": "composition was a reason we *didn't* specify extensibility<br/>", "time": "2022-03-21T13:55:49Z"}, {"author": "Martin Thomson", "text": "it was both complicated and inefficient, I think<br/>", "time": "2022-03-21T13:58:31Z"}, {"author": "Eric Orth", "text": "In draft 7: \"If an HTTP/3 datagram which carries an unknown Context ID is received, the receiver SHALL either drop that datagram silently or buffer it temporarily (on the order of a round trip) while awaiting the registration of the corresponding Context ID.\"<br/>", "time": "2022-03-21T13:59:00Z"}, {"author": "Benjamin Schwartz", "text": "There's not really a 1-RTT penalty.&nbsp;&nbsp;You just might send a duplicate packet if you use the fancy and baseline versions both in the first flight.<br/>", "time": "2022-03-21T13:59:27Z"}, {"author": "Benjamin Schwartz", "text": "Duplicate packets are basically always fine in UDP<br/>", "time": "2022-03-21T14:00:17Z"}, {"author": "Benjamin Schwartz", "text": "Pro tip: use the mute button on the bottom right to avoid hearing the room reverb while speaking<br/>", "time": "2022-03-21T14:00:50Z"}, {"author": "jhoyla", "text": "Could you send two datagrams, one assuming support and one assuming no support, and have some way for the server to unambiguously select one?<br/>", "time": "2022-03-21T14:01:57Z"}, {"author": "Benjamin Schwartz", "text": "jhoyla: Not in the current spec<br/>", "time": "2022-03-21T14:02:29Z"}, {"author": "Ian Swett", "text": "Q, probably for the design team.&nbsp;&nbsp;Is there a reason we can't advertise support of extensions in SETTINGS and then the sender would always know what's supported before using them<br/>", "time": "2022-03-21T14:02:56Z"}, {"author": "Martin Thomson", "text": "given that the current spec says nothing, I guess that you could do anything you like<br/>", "time": "2022-03-21T14:02:57Z"}, {"author": "Martin Thomson", "text": "sending both seems good for something like a QUIC Initial<br/>", "time": "2022-03-21T14:03:09Z"}, {"author": "Martin Thomson", "text": "why not {host} and {port} ?<br/>", "time": "2022-03-21T14:03:21Z"}, {"author": "Benjamin Schwartz", "text": "Ian: SETTINGS is \"hop by hop\", headers are \"end to end\"<br/>", "time": "2022-03-21T14:03:35Z"}, {"author": "jhoyla", "text": "Would it be worth trying to define an XOR packet selection feature?<br/>", "time": "2022-03-21T14:03:38Z"}, {"author": "afrind@jabb3r.org", "text": "ian: settings are hop-by-hop and extensions are end to end.&nbsp;&nbsp;But if you have confidence that everything behind you supports extensions then you can do it in a settting<br/>", "time": "2022-03-21T14:03:51Z"}, {"author": "Martin Thomson", "text": ".well-known is correct<br/>", "time": "2022-03-21T14:04:28Z"}, {"author": "Mike Bishop", "text": "+1 to .well-known<br/>", "time": "2022-03-21T14:04:48Z"}, {"author": "Martin Thomson", "text": "\u00af_(\u30c4)_/\u00af<br/>", "time": "2022-03-21T14:05:03Z"}, {"author": "afrind@jabb3r.org", "text": "reminder if you want me to relay your comment at the mic, preface with mic: <br/>", "time": "2022-03-21T14:05:34Z"}, {"author": "Martin Thomson", "text": "special handling is what we're looking for here<br/>", "time": "2022-03-21T14:05:42Z"}, {"author": "Benjamin Schwartz", "text": "I think the default should be URL parameters, not path components<br/>", "time": "2022-03-21T14:05:58Z"}, {"author": "Ian Swett", "text": "Thanks Ben and afrind, I just had that thought after typing it out.&nbsp;&nbsp;Some of these seem like they could beHBH, not E2E, just like the internet does today with TOS, but I'd have to think more.<br/>", "time": "2022-03-21T14:06:15Z"}, {"author": "Juliusz Chroboczek", "text": "Benjamin: for my education -- why is that?<br/>", "time": "2022-03-21T14:06:31Z"}, {"author": "Martin Thomson", "text": "Benjamin Schwartz: {?host} and {?port} ?<br/>", "time": "2022-03-21T14:06:55Z"}, {"author": "Benjamin Schwartz", "text": "jhoyla: It's a fun idea but I don't see an easy way to support that<br/>", "time": "2022-03-21T14:07:13Z"}, {"author": "Martin Thomson", "text": "what about a caching proxy that falsely caches all GETs?<br/>", "time": "2022-03-21T14:07:33Z"}, {"author": "Benjamin Schwartz", "text": "jhoyla: I guess we could define a new capsule (SELECT_DATAGRAM), so this could be done in an extension<br/>", "time": "2022-03-21T14:07:59Z"}, {"author": "jhoyla", "text": "Benjamin Schwartz_web_989 Got it, thanks<br/>", "time": "2022-03-21T14:08:15Z"}, {"author": "Martin Thomson", "text": "GET is cacheable by default<br/>", "time": "2022-03-21T14:08:22Z"}, {"author": "Benjamin Schwartz", "text": "Martin: Works for me<br/>", "time": "2022-03-21T14:08:49Z"}, {"author": "afrind@jabb3r.org", "text": "do such proxies cache WS upgrades today?<br/>", "time": "2022-03-21T14:09:01Z"}, {"author": "jhoyla", "text": "The audio _is_ really bad.<br/>", "time": "2022-03-21T14:09:50Z"}, {"author": "Martin Thomson", "text": "they might have learned about WS<br/>", "time": "2022-03-21T14:09:56Z"}, {"author": "afrind@jabb3r.org", "text": "symmetric asymmetry<br/>", "time": "2022-03-21T14:10:29Z"}, {"author": "Erik Nygren", "text": "Having a new method for Extended Connect might be another option (but less consistent with WebSocket).<br/>", "time": "2022-03-21T14:10:34Z"}, {"author": "Martin Thomson", "text": "POST is probably fine for this<br/>", "time": "2022-03-21T14:11:00Z"}, {"author": "Juliusz Chroboczek", "text": "Consistency is the yoke of small minds.<br/>", "time": "2022-03-21T14:11:26Z"}, {"author": "Erik Nygren", "text": "+1 that \"CONNECT\" has such weird semantics that using something different for Extended Connect seems preferable.<br/>", "time": "2022-03-21T14:11:47Z"}, {"author": "Martin Thomson", "text": "\"CONNECT\" is definitely bad, for sure<br/>", "time": "2022-03-21T14:12:40Z"}, {"author": "afrind@jabb3r.org", "text": "Rajeev: if you type your comment I can relay<br/>", "time": "2022-03-21T14:13:44Z"}, {"author": "Jonathan Lennox", "text": "Meetecho: sound from remote participants in this room is really terrible<br/>", "time": "2022-03-21T14:13:47Z"}, {"author": "Martin Thomson", "text": "second class remote participation FTL<br/>", "time": "2022-03-21T14:14:24Z"}, {"author": "afrind@jabb3r.org", "text": ":( <br/>", "time": "2022-03-21T14:14:36Z"}, {"author": "Eric Rescorla", "text": "@MT: well, given that most of us are remote, I'm not sure who is getting the second class experience<br/>", "time": "2022-03-21T14:14:51Z"}, {"author": "Mirja K\u00fchlewind", "text": "actually I think it's not the room audio but somehow the audio is a bot choppy for some of the remote people<br/>", "time": "2022-03-21T14:15:14Z"}, {"author": "afrind@jabb3r.org", "text": "Can remote participants hear other remote participants well?<br/>", "time": "2022-03-21T14:15:23Z"}, {"author": "Eric Rescorla", "text": "yes<br/>", "time": "2022-03-21T14:15:29Z"}, {"author": "Christopher Wood", "text": "Yes.<br/>", "time": "2022-03-21T14:15:30Z"}, {"author": "afrind@jabb3r.org", "text": "interesting<br/>", "time": "2022-03-21T14:15:37Z"}, {"author": "Mirja K\u00fchlewind", "text": "if you speak loud and reasonably slow it's fine.<br/>", "time": "2022-03-21T14:15:43Z"}, {"author": "Martin Thomson", "text": "rajeev was poor<br/>", "time": "2022-03-21T14:15:47Z"}, {"author": "Martin Thomson", "text": "but when he spoke up, it came through clearly enough<br/>", "time": "2022-03-21T14:15:56Z"}, {"author": "Meetecho", "text": "Looking into it<br/>", "time": "2022-03-21T14:15:57Z"}, {"author": "Eric Rescorla", "text": "yes, but I heard MT fine and I can hear Erik fine<br/>", "time": "2022-03-21T14:16:04Z"}, {"author": "lpardue", "text": "+1 Erik<br/>", "time": "2022-03-21T14:16:06Z"}, {"author": "Eric Rescorla", "text": "I'm sorry, but I don't understand Erik's point<br/>", "time": "2022-03-21T14:16:47Z"}, {"author": "Martin Thomson", "text": "the thing with Upgrade is that the method doesn't matter<br/>", "time": "2022-03-21T14:17:18Z"}, {"author": "Eric Orth", "text": "Many speakers have been fine remotely, but a few haven't and those seem to line up with those that the in-person people heard the worst.<br/>", "time": "2022-03-21T14:17:18Z"}, {"author": "Eric Rescorla", "text": "OK, MT's argument persuaded me<br/>", "time": "2022-03-21T14:18:17Z"}, {"author": "Jonathan Lennox", "text": "Do we care at all about what TLS interception proxies will do to this?<br/>", "time": "2022-03-21T14:18:30Z"}, {"author": "Erik Nygren", "text": "ekr:&nbsp;&nbsp;CONNECT has special semantics that doesn't support multi-tenancy.&nbsp;&nbsp;(ie, the Host header in it defines the destination, not the Origin.)&nbsp;&nbsp;Extended Connect (eg, websockets) does have both an Origin in the Host header and a destination.&nbsp;&nbsp;Mixing semantics in CONNECT seems messy.<br/>", "time": "2022-03-21T14:18:40Z"}, {"author": "Eric Rescorla", "text": "@jonathan: yes, but mostly if it creates a security issue, not a failure<br/>", "time": "2022-03-21T14:19:26Z"}, {"author": "Tommy Pauly", "text": "A new method for something that we don't expect people to ever really use seems a bit heavy?<br/>", "time": "2022-03-21T14:20:28Z"}, {"author": "Martin Thomson", "text": "I don't like a new method.&nbsp;&nbsp;Maybe PRI<br/>", "time": "2022-03-21T14:20:51Z"}, {"author": "Ted Hardie", "text": "I don't think a new method is worth the bang for the buck<br/>", "time": "2022-03-21T14:21:09Z"}, {"author": "Erik Nygren", "text": "A new well-defined Extended Connect method would be potentially useful for other cases as well.<br/>", "time": "2022-03-21T14:21:30Z"}, {"author": "Eric Rescorla", "text": "Did David just get much quieter?<br/>", "time": "2022-03-21T14:21:44Z"}, {"author": "Mike Bishop", "text": "PRI is already registered.&nbsp;&nbsp;:-)<br/>", "time": "2022-03-21T14:22:11Z"}, {"author": "jhoyla", "text": "@ekr, not in person :shrug:<br/>", "time": "2022-03-21T14:22:38Z"}, {"author": "Benjamin Schwartz", "text": "I like PRI<br/>", "time": "2022-03-21T14:22:44Z"}, {"author": "Mike Bishop", "text": "It's solved for WebSockets, except that the server specifically can ignore the Upgrade and serve the targeted resource (likely a long-poll?).<br/>", "time": "2022-03-21T14:23:37Z"}, {"author": "Eric Rescorla", "text": "That was a surprising plot twist<br/>", "time": "2022-03-21T14:26:45Z"}, {"author": "Tommy Pauly", "text": "lol<br/>", "time": "2022-03-21T14:26:52Z"}, {"author": "Mike Bishop", "text": "@PHB, because intermediaries may translate to other versions along the path.<br/>", "time": "2022-03-21T14:26:54Z"}, {"author": "Rajeev RK", "text": "The GET Gets It<br/>", "time": "2022-03-21T14:26:54Z"}, {"author": "Sean Turner", "text": "Might I suggest WGLC :)<br/>", "time": "2022-03-21T14:27:21Z"}, {"author": "Tommy Pauly", "text": "Gasp!<br/>", "time": "2022-03-21T14:27:38Z"}, {"author": "Martin Thomson", "text": "it seemed like we have a few more issues open on this one around extensibiity<br/>", "time": "2022-03-21T14:28:17Z"}, {"author": "Tommy Pauly", "text": "Or rather TODOs in another document to prove extensibility before we ship it?<br/>", "time": "2022-03-21T14:28:40Z"}, {"author": "afrind@jabb3r.org", "text": "are we comfortable going to last&nbsp;&nbsp;call without the extensibility draft?<br/>", "time": "2022-03-21T14:28:46Z"}, {"author": "Christopher Wood", "text": "Note that we don't have to advance the document beyond WGLC. We can park them after WGLC while we work on extensions, if that's desired by the group.<br/>", "time": "2022-03-21T14:29:32Z"}, {"author": "Mirja K\u00fchlewind", "text": "Yes, my earlier comment applies now. I would like to at least see a first version of the extension/registration draft first.<br/>", "time": "2022-03-21T14:29:33Z"}, {"author": "Eric Orth", "text": "I don't know if I'd actually object to WGLC with things as they are, but I think I would have a slight preference to cleanup some of the extensibility stuff and point to that newly-proposed draft first.<br/>", "time": "2022-03-21T14:30:06Z"}, {"author": "lpardue", "text": "does this MTU problem have a Github issue number?<br/>", "time": "2022-03-21T14:32:40Z"}, {"author": "Eric Rescorla", "text": "Isn't this another case of \"don't do that then\"??<br/>", "time": "2022-03-21T14:32:51Z"}, {"author": "Eric Rescorla", "text": "Like you have to up-negotiate the QUIC MTU<br/>", "time": "2022-03-21T14:33:02Z"}, {"author": "Martin Thomson", "text": "yeah, this seems like another instance of the tunnel problem<br/>", "time": "2022-03-21T14:33:13Z"}, {"author": "lpardue", "text": "is it <a href=\"https://github.com/ietf-wg-masque/draft-ietf-masque-connect-ip/issues/45\" rel=\"nofollow\">https://github.com/ietf-wg-masque/draft-ietf-masque-connect-ip/issues/45</a> ?<br/>", "time": "2022-03-21T14:33:29Z"}, {"author": "jhoyla", "text": "If the link only supports 1200 MTU then isn't IPv6 already broken, irrespective of the presence of QUIC?<br/>", "time": "2022-03-21T14:33:39Z"}, {"author": "Benjamin Schwartz", "text": "Most IP tunneling schemes (IPSec, L2TP) can tunnel any IPv6 flow while running over any IPv6 route.<br/>", "time": "2022-03-21T14:33:45Z"}, {"author": "Benjamin Schwartz", "text": "jhoyla: The link has 1280 MTU, but QUIC has some overhead.<br/>", "time": "2022-03-21T14:34:02Z"}, {"author": "Martin Thomson", "text": "jhoyla: I think that the problem exists if you are at the minimum MTU for v6 support<br/>", "time": "2022-03-21T14:34:03Z"}, {"author": "Eric Kinnear", "text": "Lucas: I think #45, yes<br/>", "time": "2022-03-21T14:34:04Z"}, {"author": "lpardue", "text": "cheers<br/>", "time": "2022-03-21T14:34:30Z"}, {"author": "Ted Hardie", "text": "There's some text on MTU handling for IP in UDP in draft-xu-intarea-ip-in-udp-10.txt, if folks wanted to look at that to see if it is worth lifting.<br/>", "time": "2022-03-21T14:34:35Z"}, {"author": "Martin Thomson", "text": "segmentation and reassembly seems like another option<br/>", "time": "2022-03-21T14:34:39Z"}, {"author": "Philipp Tiesel", "text": "So IP fragmentation inside Connect-IP?<br/>", "time": "2022-03-21T14:35:11Z"}, {"author": "Ted Hardie", "text": "I am not sure why that didn't progress, though, so definitely convince yourself its the right approach first.<br/>", "time": "2022-03-21T14:35:20Z"}, {"author": "Rajeev RK", "text": "Allow segmentation and reassembly&nbsp;&nbsp;+&nbsp;&nbsp;documenting this is a non-optimal behaviour that is encountered in the Min-MTU Cases<br/>", "time": "2022-03-21T14:35:45Z"}, {"author": "Sean Turner", "text": "wmahahaha<br/>", "time": "2022-03-21T14:36:42Z"}, {"author": "Mike Bishop", "text": "Allowing DATAGRAM capsules seems like the simplest solution.<br/>", "time": "2022-03-21T14:36:44Z"}, {"author": "Philipp Tiesel", "text": "Extension sounds bad\u2026 but optional behaviour<br/>", "time": "2022-03-21T14:36:45Z"}, {"author": "Benjamin Schwartz", "text": "MIke: It doesn't actually solve the problem (in some extreme topologies)<br/>", "time": "2022-03-21T14:37:13Z"}, {"author": "Martin Thomson", "text": "draft-xu seems to just recommend PMTUD<br/>", "time": "2022-03-21T14:37:29Z"}, {"author": "jhoyla", "text": "Benjamin Schwartz_web_989 I nearly parsed that as \"MIC:\"<br/>", "time": "2022-03-21T14:38:02Z"}, {"author": "Martin Thomson", "text": "the interesting part is when the MTU drops below the minimum, mid session<br/>", "time": "2022-03-21T14:38:17Z"}, {"author": "Eric Rescorla", "text": "IPv4 is a cool version of IPv6 that uses less bandwidth<br/>", "time": "2022-03-21T14:39:20Z"}, {"author": "Giles Heron", "text": "@Martin, you mean if the packet numbers grow?<br/>", "time": "2022-03-21T14:39:39Z"}, {"author": "Martin Thomson", "text": "Giles, probably stream numbers growing longer<br/>", "time": "2022-03-21T14:39:56Z"}, {"author": "Giles Heron", "text": "ok<br/>", "time": "2022-03-21T14:40:00Z"}, {"author": "Martin Thomson", "text": "but also because the path changes<br/>", "time": "2022-03-21T14:40:03Z"}, {"author": "Martin Thomson", "text": "you can also have the connection IDs get longer suddenly<br/>", "time": "2022-03-21T14:40:14Z"}, {"author": "Juliusz Chroboczek", "text": "Martin +1<br/>", "time": "2022-03-21T14:40:21Z"}, {"author": "Giles Heron", "text": "another gotcha of variable length encoding ;)<br/>", "time": "2022-03-21T14:40:33Z"}, {"author": "Eric Rescorla", "text": "@MT: I think we can treat that as a failure.<br/>", "time": "2022-03-21T14:40:35Z"}, {"author": "Mirja K\u00fchlewind", "text": "yes let's do it all<br/>", "time": "2022-03-21T14:40:42Z"}, {"author": "Eric Rescorla", "text": "I.e., my position is that we will soon find out if this is a real problem and then we can fix it<br/>", "time": "2022-03-21T14:40:55Z"}, {"author": "Jonathan Lennox", "text": "Wouldn't fragmentation and reassembly (at the outer UDP layer of the QUIC packets) just work, at least as much as it ever does?<br/>", "time": "2022-03-21T14:41:26Z"}, {"author": "Benjamin Schwartz", "text": "Jonathan: QUIC prohibits fragmentation<br/>", "time": "2022-03-21T14:41:39Z"}, {"author": "Martin Thomson", "text": "I think so too.&nbsp;&nbsp;If you are that close to the limit, then you might want to fail early, even.<br/>", "time": "2022-03-21T14:41:44Z"}, {"author": "Benjamin Schwartz", "text": "We could drop that restriction for QUIC Datagram...<br/>", "time": "2022-03-21T14:41:54Z"}, {"author": "Martin Thomson", "text": "Benjamin Schwartz: masque could choose to ignore DF bits or non-fragmentation signals<br/>", "time": "2022-03-21T14:42:38Z"}, {"author": "jhoyla", "text": "Meetecho&nbsp;&nbsp;the remote audio is almost unintelligible in the room.<br/>", "time": "2022-03-21T14:42:49Z"}, {"author": "David Schinazi", "text": "Ah I put in headphones and I can now hear everyone again :-)<br/>", "time": "2022-03-21T14:42:52Z"}, {"author": "Juliusz Chroboczek", "text": "Benjamin: is it possible to switch fragmentation on/off on a per-packet basis with common networking APIs?<br/>", "time": "2022-03-21T14:43:13Z"}, {"author": "Martin Thomson", "text": "Juliusz: I believe that it is possible, but you should ask Eric Kinnear.<br/>", "time": "2022-03-21T14:43:43Z"}, {"author": "David Schinazi", "text": "@Juliusz: It's a socket option, not sure what happens if you toggle it on TCP mid stream<br/>", "time": "2022-03-21T14:44:07Z"}, {"author": "Benjamin Schwartz", "text": "Martin: That would essentially reintroduce forward-fragmentation, which was removed from IPv6<br/>", "time": "2022-03-21T14:44:13Z"}, {"author": "Meetecho", "text": "Sent someone to the room<br/>", "time": "2022-03-21T14:44:34Z"}, {"author": "jhoyla", "text": "Tommy Pauly_web_446 Please could you summarise Rajeev for the local room?<br/>", "time": "2022-03-21T14:44:38Z"}, {"author": "Martin Thomson", "text": "What Rajeev says is \"the packets must flow\"<br/>", "time": "2022-03-21T14:45:05Z"}, {"author": "Martin Thomson", "text": "with an option to turn off whatever it is that made them work<br/>", "time": "2022-03-21T14:45:18Z"}, {"author": "Jonathan Lennox", "text": "David: in this case you'd be toggling it on UDP though, which is better defined (though non-atomic so you need to make sure you're not writing to the UDP socket from more than one thread).<br/>", "time": "2022-03-21T14:45:46Z"}, {"author": "Juliusz Chroboczek", "text": "(Wow.&nbsp;&nbsp;That's a concise and to-the-point summary.)<br/>", "time": "2022-03-21T14:45:49Z"}, {"author": "jhoyla", "text": "\ud83d\ude4f<br/>", "time": "2022-03-21T14:46:03Z"}, {"author": "Eric Rescorla", "text": "+1 tp Davod<br/>", "time": "2022-03-21T14:46:58Z"}, {"author": "jhoyla", "text": "Everyone except people are on borked networks<br/>", "time": "2022-03-21T14:47:01Z"}, {"author": "jhoyla", "text": "who are on*<br/>", "time": "2022-03-21T14:47:12Z"}, {"author": "David Schinazi", "text": "But we can handle this flavor on borked networks with an extension if and when we realize such networks really exist<br/>", "time": "2022-03-21T14:48:28Z"}, {"author": "David Schinazi", "text": "flavor of*<br/>", "time": "2022-03-21T14:48:33Z"}, {"author": "Juliusz Chroboczek", "text": "I think that the authors are thinking of a (possibly distributed) datacenter, where routing doesn't change much.&nbsp;&nbsp;Others are thinking of using that closer to the edge, and are worried about a path stopping working when the user moves from WiFi to cellular or some such.<br/>", "time": "2022-03-21T14:48:48Z"}, {"author": "Martin Thomson", "text": "a path that supports v6 should be able to support QUIC in QUIC unless you go crazy with connection IDs<br/>", "time": "2022-03-21T14:48:57Z"}, {"author": "David Schinazi", "text": "But is it common for cellular and Wi-Fi to have an MTU below 1300?<br/>", "time": "2022-03-21T14:49:15Z"}, {"author": "Martin Thomson", "text": "nah, most networks are well over 1300<br/>", "time": "2022-03-21T14:49:37Z"}, {"author": "Jonathan Lennox", "text": "Depends how many layers of tunneling you're going over<br/>", "time": "2022-03-21T14:49:52Z"}, {"author": "jhoyla", "text": "I'm sure it is somewhere, the internet is full of weird corners.<br/>", "time": "2022-03-21T14:49:53Z"}, {"author": "Eric Rescorla", "text": "Sure, with enough tunnelling you can always get into this situation<br/>", "time": "2022-03-21T14:50:04Z"}, {"author": "Eric Rescorla", "text": "But note that that's true for IPv6 no matter what<br/>", "time": "2022-03-21T14:50:12Z"}, {"author": "Martin Thomson", "text": "QUIC over IP tunnel over QUIC over IP tunnel over QUIC over IP tunnel over QUIC over IP tunnel over QUIC over IP tunnel over ...<br/>", "time": "2022-03-21T14:50:31Z"}, {"author": "Jonathan Lennox", "text": "If you want to do TOR-UDP using MASQUE...<br/>", "time": "2022-03-21T14:50:48Z"}, {"author": "Martin Thomson", "text": "it's also true for IPv4, but you get more tunnels before it's a problem<br/>", "time": "2022-03-21T14:50:55Z"}, {"author": "Eric Kinnear", "text": "(From earlier: IIRC you can toggle the socket option per packet if you want, it would also be interesting to see if other middleboxes choke when that happens)<br/>", "time": "2022-03-21T14:51:02Z"}, {"author": "Benjamin Schwartz", "text": "UDP might not have a minimum MTU, but sufficiently small UDP is useless so ...<br/>", "time": "2022-03-21T14:51:47Z"}, {"author": "jhoyla", "text": "Two IETFers, three opinions.<br/>", "time": "2022-03-21T14:52:28Z"}, {"author": "David Schinazi", "text": "Lorenzo, please read the drafts :-)<br/>", "time": "2022-03-21T14:53:48Z"}, {"author": "Juliusz Chroboczek", "text": "WebRTC uses 1024-octet datagrams, if memory serves, so if that's typical, you've got a lot more margin with UDP.&nbsp;&nbsp;But yes, there's a similar problem.<br/>", "time": "2022-03-21T14:53:55Z"}, {"author": "Juliusz Chroboczek", "text": "Let's call it the Cantor-Weierstrass problem.<br/>", "time": "2022-03-21T14:54:05Z"}, {"author": "jhoyla", "text": "You could have an atomic unreliable stream<br/>", "time": "2022-03-21T14:54:23Z"}, {"author": "jhoyla", "text": "Either all packets or none delivered.<br/>", "time": "2022-03-21T14:54:34Z"}, {"author": "David Schinazi", "text": "This is my point about complexity, we're fraying into set theory<br/>", "time": "2022-03-21T14:54:59Z"}, {"author": "Juliusz Chroboczek", "text": "Oh, sure.&nbsp;&nbsp;Your plan to just standardise the simple thing and worry about extending applicability when (if) it turns out to be needed is quite reasonable.<br/>", "time": "2022-03-21T14:56:16Z"}, {"author": "David Schinazi", "text": "Thanks :-)<br/>", "time": "2022-03-21T14:56:45Z"}, {"author": "Philipp Tiesel", "text": "So, could we implement a form of \"limited segmentation\" that just supports a few ways to split packets?<br/>", "time": "2022-03-21T14:57:53Z"}, {"author": "Martin Thomson", "text": "I'm fairly happy with the yolo approach Ekr advocates for.<br/>", "time": "2022-03-21T14:58:01Z"}, {"author": "Martin Thomson", "text": "fragmentation and reassembly with a way to abandon retransmissions is probably what we want; that leads to higher loss, but it is better than HOLB.<br/>", "time": "2022-03-21T14:58:58Z"}, {"author": "Martin Thomson", "text": "but that can wait<br/>", "time": "2022-03-21T14:59:04Z"}, {"author": "Juliusz Chroboczek", "text": "HOLB?<br/>", "time": "2022-03-21T14:59:41Z"}, {"author": "afrind@jabb3r.org", "text": "head of line blocking<br/>", "time": "2022-03-21T14:59:51Z"}, {"author": "Juliusz Chroboczek", "text": "(Ah, head-of line blocking)<br/>", "time": "2022-03-21T14:59:56Z"}, {"author": "Juliusz Chroboczek", "text": "ty<br/>", "time": "2022-03-21T14:59:58Z"}, {"author": "Giles Heron", "text": "path shifts or packet number grows?&nbsp;&nbsp;That case doesn't occur with most tunnel types, but does with QUIC?<br/>", "time": "2022-03-21T15:00:02Z"}, {"author": "Philipp Tiesel", "text": "but to do that, we cannot allow to fall through all the way to HTTP/2<br/>", "time": "2022-03-21T15:00:05Z"}, {"author": "Martin Thomson", "text": "giles, paths do occasionally flap around and get a different MTU in an essentially random fashion<br/>", "time": "2022-03-21T15:01:13Z"}, {"author": "Giles Heron", "text": "yup - I know Martin<br/>", "time": "2022-03-21T15:01:23Z"}, {"author": "Giles Heron", "text": "but variable length encap is a new failure mode?<br/>", "time": "2022-03-21T15:01:48Z"}, {"author": "Martin Thomson", "text": "it probably won't come up unless you have a very fine path MTU detection<br/>", "time": "2022-03-21T15:02:16Z"}, {"author": "Eric Rescorla", "text": "I'd be interested in hearing someone propose an algorithm for detecting when you need to start falling back to smaller datagrams<br/>", "time": "2022-03-21T15:02:18Z"}, {"author": "jhoyla", "text": "Paths can be asymmetric, so could you have a 1200 MTU on the outbound but a 1500 MTU on the return?<br/>", "time": "2022-03-21T15:02:27Z"}, {"author": "Martin Thomson", "text": "most people settle for an MTU that is approximate<br/>", "time": "2022-03-21T15:02:35Z"}, {"author": "Philipp Tiesel", "text": "Falling back to capsules makes it much easier to slide in an fragmentation extension.<br/>", "time": "2022-03-21T15:02:48Z"}, {"author": "Martin Thomson", "text": "jhoyla: anything is possible<br/>", "time": "2022-03-21T15:02:49Z"}, {"author": "Eric Rescorla", "text": "Like, how many missing packets of 1295 bytes would make you want to do some kind of PMTU rediscovery/backoff<br/>", "time": "2022-03-21T15:02:56Z"}, {"author": "Martin Thomson", "text": "I certainly wouldn't want to assume symmetry<br/>", "time": "2022-03-21T15:03:23Z"}, {"author": "jhoyla", "text": "@MT Does that make it difficult to detect that you're in this case?<br/>", "time": "2022-03-21T15:03:30Z"}, {"author": "Giles Heron", "text": "anything is possible.&nbsp;&nbsp; Troubleshooting-wise weird failure modes are the hardest to debug....<br/>", "time": "2022-03-21T15:03:34Z"}, {"author": "Martin Thomson", "text": "think about satellite links with upload on a terrestrial path<br/>", "time": "2022-03-21T15:03:42Z"}, {"author": "Philipp Tiesel", "text": "For the detection of loss\u2026 do we need some form of reliable send/recv reports?<br/>", "time": "2022-03-21T15:03:52Z"}, {"author": "Martin Thomson", "text": "jhoyla: PMTUD is one way always<br/>", "time": "2022-03-21T15:04:50Z"}, {"author": "Juliusz Chroboczek", "text": "Philipp, I suspect that draft-schwartz-masque-h3-datagram-ping-01 is related.<br/>", "time": "2022-03-21T15:05:14Z"}, {"author": "Rajeev RK", "text": "Lorenzo encapsulated my point perfectly....<br/>", "time": "2022-03-21T15:05:42Z"}, {"author": "Martin Thomson", "text": "so we have a choice between error signals and a performance bug.&nbsp;&nbsp;I'm a fan of failing hard.<br/>", "time": "2022-03-21T15:07:03Z"}, {"author": "Eric Rescorla", "text": "This is my argument as well :)<br/>", "time": "2022-03-21T15:07:26Z"}, {"author": "Mike Bishop", "text": "That sums up Masque pretty well, doesn't it?<br/>", "time": "2022-03-21T15:07:39Z"}, {"author": "Martin Thomson", "text": "if you can't tolerate loss, use TCP<br/>", "time": "2022-03-21T15:07:56Z"}, {"author": "Mirja K\u00fchlewind", "text": "If the MTU changes it's maybe harder but if the MTU is below 1300 from the beginning I don't see a reason to fail<br/>", "time": "2022-03-21T15:08:12Z"}, {"author": "Martin Thomson", "text": "using capsules for your IP packets - from the outset or otherwise - is a fairly big difference in performance profile<br/>", "time": "2022-03-21T15:10:31Z"}, {"author": "Eric Rescorla", "text": "It seems like a pretty big price to pay for a situation which we expect to happen rarely<br/>", "time": "2022-03-21T15:10:57Z"}, {"author": "Juliusz Chroboczek", "text": "As David suggested \u2014 standardise hard fail, wait for deployment experience to see if something more complex is required.<br/>", "time": "2022-03-21T15:12:58Z"}, {"author": "Martin Thomson", "text": "this is the MASQUE proxy acting as a router, so why shouldn't it send ICMP?<br/>", "time": "2022-03-21T15:12:59Z"}, {"author": "Juliusz Chroboczek", "text": "DoS attack?<br/>", "time": "2022-03-21T15:17:03Z"}, {"author": "jhoyla", "text": "Philipp Tiesel_web_322 if you want something relayed to the mic just drop it here prefaced with @mic<br/>", "time": "2022-03-21T15:18:10Z"}, {"author": "Eric Kinnear", "text": "Philipp: Feel free to type into the chat or rejoin the queue once audio is happy again :) <br/>", "time": "2022-03-21T15:18:18Z"}, {"author": "Eric Rescorla", "text": "Oh, that's embarassing. BCP38<br/>", "time": "2022-03-21T15:19:36Z"}, {"author": "Eric Rescorla", "text": "Too many BCPs<br/>", "time": "2022-03-21T15:19:42Z"}, {"author": "Martin Thomson", "text": "this is not QUIC though<br/>", "time": "2022-03-21T15:20:03Z"}, {"author": "Philipp Tiesel", "text": "So in the chat\u2026 inventing a new mechanism makes the world, especially in regulated enlivenments, more complicated\u2026 so ICMP inside the tunnel is a good guidance. Still, if we want to signal bad behaviour with respect the tunnel configuration, sending the error as a capsule as a \"protocol error\" makes sense and tun it in an ICMP on the client side makes sense<br/>", "time": "2022-03-21T15:20:14Z"}, {"author": "Martin Thomson", "text": "an IP router advertises routes too, but it has to handle stuff outside of those<br/>", "time": "2022-03-21T15:20:35Z"}, {"author": "jhoyla", "text": "Philipp Tiesel_web_322 do you want that said at the mic?<br/>", "time": "2022-03-21T15:20:54Z"}, {"author": "Martin Thomson", "text": "I think that David's idea of \"this is just IP routing\" is best<br/>", "time": "2022-03-21T15:20:57Z"}, {"author": "Juliusz Chroboczek", "text": "+1<br/>", "time": "2022-03-21T15:21:08Z"}, {"author": "Philipp Tiesel", "text": "@jhoyla yes, please<br/>", "time": "2022-03-21T15:21:15Z"}, {"author": "afrind@jabb3r.org", "text": "Phillipp: want me to relay at the mic?<br/>", "time": "2022-03-21T15:21:23Z"}, {"author": "afrind@jabb3r.org", "text": "oops jhoyla has it<br/>", "time": "2022-03-21T15:21:49Z"}, {"author": "Martin Thomson", "text": "though I might acknowledge that someone might choose to be stricter, I don't think that works, because who knows how tightly coupled the client is<br/>", "time": "2022-03-21T15:21:49Z"}, {"author": "Rajeev RK", "text": "Note Editor&nbsp;&nbsp;: I was saying that Silently Dropping packets should be strongly discouraged in the draft text, since the IP router tunnel use case is more limited, and many of the good reasons for silent drop in respect of general purpose IP routers. Here, since both endpoints of the tunnel are more tightly negotiated, ICMP signaling is just more polite.<br/>", "time": "2022-03-21T15:21:59Z"}, {"author": "Rajeev RK", "text": "Just clarifying since the notes editor seemed to miss my audio<br/>", "time": "2022-03-21T15:22:50Z"}, {"author": "Martin Thomson", "text": "copied for you<br/>", "time": "2022-03-21T15:22:58Z"}, {"author": "jhoyla", "text": "Rajeev RK_web_328 not sure why but your onsite audio is such a choppy mess it's totally unintelligible.<br/>", "time": "2022-03-21T15:23:32Z"}, {"author": "Mirja K\u00fchlewind", "text": "@rajeev we don't hear you well in the room but you can also edit the notes yourself<br/>", "time": "2022-03-21T15:24:05Z"}, {"author": "Juliusz Chroboczek", "text": "It sounds exactly like Opus's loss compensation overwhelmed.<br/>", "time": "2022-03-21T15:24:20Z"}, {"author": "Rajeev RK", "text": "would love some guidance on interop testing<br/>", "time": "2022-03-21T15:24:49Z"}, {"author": "lpardue", "text": "in-room audio wasn't great - please check minutes for accuracy <br/>", "time": "2022-03-21T15:24:56Z"}, {"author": "Philipp Tiesel", "text": "Thanks eveyone, bye<br/>", "time": "2022-03-21T15:25:05Z"}, {"author": "Mirja K\u00fchlewind", "text": "Thx!<br/>", "time": "2022-03-21T15:25:14Z"}, {"author": "Martin Thomson", "text": "I think that this was bad acoustics design (echo primarily)<br/>", "time": "2022-03-21T15:25:16Z"}, {"author": "Rajeev RK", "text": "thanks everyone...<br/>", "time": "2022-03-21T15:25:21Z"}]