[15:09:06] mpiraux leaves the room: Disconnected: No route to host
[15:10:19] cabo joins the room
[15:35:22] cabo leaves the room
[16:08:22] mpiraux joins the room
[16:33:27] Dan Wing joins the room
[16:39:38] cabo joins the room
[16:42:23] Dan Wing leaves the room
[17:10:22] cabo leaves the room
[18:44:57] achernya joins the room
[19:35:21] cabo joins the room
[19:36:57] Glen (AMS IT) joins the room
[19:39:16] Glen (AMS IT) leaves the room
[19:42:59] Glen (AMS IT) joins the room
[19:43:45] Glen (AMS IT) leaves the room
[19:52:25] Glen (AMS IT) joins the room
[20:46:23] dschinazi@jab.im joins the room
[21:05:40] Zaheduzzaman Sarker joins the room
[21:42:00] ek.ietf joins the room
[21:49:41] kbarabad joins the room
[21:53:51] jhoyla joins the room
[21:56:28] adam joins the room
[21:56:47] Glen (AMS IT) leaves the room
[21:56:52] Nick Sullivan joins the room
[21:56:58] Jonathan Lennox joins the room
[21:57:16] Shuai Zhao joins the room
[21:57:31] spencerdawkins joins the room
[21:57:35] <adam> Please make sure you sign the bluesheet at the bottom of https://etherpad.ietf.org:9009/p/notes-ietf-107-masque?useMonospaceFont=true
[21:57:54] cvmiller joins the room
[21:57:58] Atarashi Yoshifumi joins the room
[21:58:13] tfpauly joins the room
[21:58:28] Yoshiro YONEYA joins the room
[21:58:30] lpardue joins the room
[21:58:32] Thomas Peterson joins the room
[21:59:23] Cullen Jennings joins the room
[21:59:37] Glen (AMS IT) joins the room
[22:00:24] carrickdb@jabber.hot-chilli.net joins the room
[22:00:34] csperkins joins the room
[22:00:40] ihlar joins the room
[22:00:55] msk joins the room
[22:01:01] Martin Thomson joins the room
[22:01:03] Mirja joins the room
[22:01:23] <carrickdb@jabber.hot-chilli.net> testing since my messages weren't working earlier
[22:01:26] <carrickdb@jabber.hot-chilli.net> yay
[22:01:36] <Glen (AMS IT)> You're here now.
[22:01:50] Alexey Melnikov joins the room
[22:02:29] watson17 joins the room
[22:03:18] Ross joins the room
[22:03:41] Karl Kathuria joins the room
[22:04:06] stf joins the room
[22:04:18] Amelia Andersdotter joins the room
[22:04:37] Ted.h joins the room
[22:05:15] <lpardue> Hello MASQUE attendees. I will be your Jabber scribe in these interesting times. If you would like me to relay a comment to the microphone on your behalf please @ me
[22:05:58] johnk joins the room
[22:05:59] Andrew Campling joins the room
[22:06:11] sftcd joins the room
[22:06:14] mbaushke@jabber.hot-chilli.net joins the room
[22:06:26] afrind joins the room
[22:07:12] <Martin Thomson> it's totally solveable, but it is likely down to a choice rather than a concrete limitation
[22:07:19] Eric Vyncke joins the room
[22:07:54] tim costello joins the room
[22:07:57] <Jonathan Lennox> Yeah, "don't scrape something that isn't visible on screen" is a reasonable policy choice, but can end up annoying?
[22:08:13] york@jabber.isoc.org joins the room
[22:08:18] <tfpauly> Hey, mas(k/que)s are in high demand! This is a very relevant and useful group!
[22:08:39] xp29srs joins the room
[22:08:39] <dschinazi@jab.im> I did not see that coming when I picked the name... 😷
[22:08:51] keithmoore joins the room
[22:09:06] <spencerdawkins> Tommy, we see what you did there ...
[22:09:12] <tfpauly> :)
[22:09:27] Magnus Westerlund joins the room
[22:10:02] chi.jiun.su joins the room
[22:10:12] <tfpauly> I can note take if needed
[22:10:21] Kathleen joins the room
[22:10:25] Ben Schwartz joins the room
[22:10:30] <tfpauly> You’re welcome!
[22:10:35] martin.duke joins the room
[22:10:37] Bernard Aboba joins the room
[22:11:13] Eric Kinnear joins the room
[22:11:14] sureshk@jabber.org joins the room
[22:11:14] Alissa Cooper joins the room
[22:11:27] ssahib joins the room
[22:11:52] Andrew Campling leaves the room
[22:11:56] Mike Bishop joins the room
[22:12:11] Philipp S. Tiesel joins the room
[22:12:27] Steve Todd joins the room
[22:12:52] dragana joins the room
[22:13:29] hta joins the room
[22:13:32] <carrickdb@jabber.hot-chilli.net> Jana (I think?) just so you know, I am laughing at all your jokes. :)
[22:14:06] <lpardue> don't encourage him!
[22:14:09] <tfpauly> That’s the problem with these virtual rooms. There’s no audible peanut gallery!
[22:14:12] dkg joins the room
[22:14:15] <sureshk@jabber.org> Really?
[22:14:28] <carrickdb@jabber.hot-chilli.net> Yeah, major negative of virtual conferences
[22:14:36] mnot joins the room
[22:15:02] Cindy Morgan joins the room
[22:15:13] kaduk@jabber.org/barnowl joins the room
[22:15:32] <Martin Thomson> a complete lack of feedback is a serious issue
[22:15:43] <jhoyla> There should be a "very quiet mic" option, so that your boos (and cheers) can still be heard.
[22:15:44] <Jonathan Lennox> I can hold my mic up to my speaker
[22:15:52] <kaduk@jabber.org/barnowl> I thought we tried to avoid audio feedback...
[22:16:01] Pete Resnick joins the room
[22:16:04] joe S joins the room
[22:16:08] <carrickdb@jabber.hot-chilli.net> > "very quiet mic" option +1
[22:16:15] John Mah joins the room
[22:16:23] <jhoyla> Jonathan Lennox :facepalm:
[22:16:27] <lpardue> for any late joiners, I am your Jabber scribe this evening
[22:16:31] m&m joins the room
[22:17:17] <sureshk@jabber.org> Thanks Lucas!
[22:17:49] <lpardue> slide 3
[22:18:04] <watson17> where are the blue sheets? the only etherpad i see is for minutes
[22:18:06] Dan McArdle joins the room
[22:18:11] <kaduk@jabber.org/barnowl> At the bottom of the etherpad
[22:18:17] <lpardue> s4
[22:18:17] Eric Kinnear leaves the room
[22:18:39] <lpardue> s5
[22:18:47] armfazh joins the room
[22:18:51] <Martin Thomson> who is running the use cases session?
[22:19:17] Greg Wood joins the room
[22:19:22] <Mirja> me
[22:19:23] <dschinazi@jab.im> Mirja for most use-cases, Alex Chernyakhovsky for the part about QBONE
[22:19:25] <Mirja> mostly
[22:19:44] <lpardue> s6
[22:20:02] Christian Huitema joins the room
[22:20:04] <jhoyla> :joy: Rules of Engagement.
[22:20:53] <watson17> to be sure it's the right etherpad: is my name on it
[22:21:01] <mbaushke@jabber.hot-chilli.net> Will the slides be posted someplace?
[22:21:09] <lpardue> s7
[22:21:10] ekr@jabber.org joins the room
[22:21:11] <dschinazi@jab.im> https://datatracker.ietf.org/meeting/107/materials/slides-107-masque-masque-master-slide-deck
[22:21:19] <sftcd> wonder will we get the usual 5 minute statement with a clarifying question at the end in a virtual BoF? :-)
[22:21:20] Kazunori Fujiwara joins the room
[22:21:23] <Martin Thomson> watson17: I don't see a watson on there
[22:21:37] leifj joins the room
[22:21:43] <jhoyla> Sorry Watson, you haven't made it.
[22:21:46] <watson17> link to the blue sheets?
[22:21:51] <lpardue> s8
[22:21:51] Eric Kinnear joins the room
[22:21:56] <Martin Thomson> https://etherpad.ietf.org:9009/p/notes-ietf-107-masque?useMonospaceFont=true
[22:22:18] GF joins the room
[22:22:46] <watson17> i think the agenda item might have a typo in that link
[22:23:10] <Martin Thomson> I don't understand the CC thing, and I suspect that it is an important point here
[22:23:16] <lpardue> s9
[22:23:18] StephenBotzko joins the room
[22:23:21] <ekr@jabber.org> Yeah, I'm not sure that is an asset
[22:23:27] jpc joins the room
[22:23:40] Eric Kinnear leaves the room
[22:23:40] <ekr@jabber.org> This seems like a situation in which we might not want congestion control (cf. DTLS)
[22:23:51] <jpc> 4br3t3S3s4m0
[22:24:01] jpc leaves the room
[22:24:21] stf leaves the room
[22:24:43] merm joins the room
[22:25:05] Wes Hardaker joins the room
[22:25:07] <lpardue> s10
[22:25:25] stf joins the room
[22:26:07] <lpardue> s11
[22:26:09] <Magnus Westerlund> @Martin Thomson the really simplest is just by splitting the feedback loop into two parts you get quicker response. There are cases where you can optimize the congestion control based on knowledge of the path between client and proxy. There is also the possibility to do local repair, for example to fix wifi losses on the local side of a long path.
[22:27:03] merm leaves the room: Disconnected: closed
[22:27:11] <Martin Thomson> Magnus Westerlund: I get that, in theory, but that doesn't work unless the proxy is originating packets for the e2e flow.  So it's not really e2e.
[22:27:23] <lpardue> s12
[22:27:59] merm joins the room
[22:28:00] <Martin Thomson> The local repair thing is probably worth looking at, but that requires that the "proxy" span the portion of the network that requires special services.
[22:28:08] <Ted.h> So we also need socks-over-QUIC?
[22:28:28] <spencerdawkins> Martin - if this stuff works, we don't have to relitigate TCP accelerators ;-)
[22:28:33] <ekr@jabber.org> what if we just invented a proxy that let you proxy UDP
[22:28:41] <Martin Thomson> It's a question of whether this is better as a link-layer function.  After all, WiFi and cellular already do that stuff.
[22:28:55] <tfpauly> Hopefully proxy UDP better than SOCKS does
[22:29:06] <ekr@jabber.org> sure
[22:29:11] <ek.ietf> right, what if there was HTTP QONNECT that would make a quic connection
[22:29:23] <lpardue> s13
[22:29:24] <Martin Thomson> ekr@jabber.org: you mean like Traversal Using Relays, maybe around NAT?
[22:29:24] <ekr@jabber.org> ek.ietf: no, I just want it to make a raw UDP connection
[22:29:28] <Jonathan Lennox> Isn't there ongoing work on a SOCKS6?
[22:29:37] <ekr@jabber.org> MT: yes, basically
[22:29:37] <spencerdawkins> Is it obvious how many of the existing proxy mechanisms we're trying to replace/how many we have to replace to declare a win?
[22:29:52] <ekr@jabber.org> Perhaps it could run over DTLS
[22:29:58] <Eric Vyncke> @JL sock6 is in intarea indeed
[22:30:12] <Magnus Westerlund> @Martin Thomson: If you have a information channel between the proxy and the end-point you can provide information that enables the optimization.
[22:30:23] <ekr@jabber.org> As far as I can tell, the major benefit here is that people want to run H3, so it's convenient to proxy stuff over this
[22:30:38] jpc joins the room
[22:30:39] <ekr@jabber.org> @Magnus: at the cost of telling the proxy stuff.
[22:30:45] <ekr@jabber.org> Which it's not clear we want to do
[22:30:53] <lpardue> s14
[22:31:08] <Ben Schwartz> lpardue: What is s#?
[22:31:16] <dkg> slide numbers
[22:31:30] <keithmoore> 'proxy' may not be the best term.   normally a proxy is a party that acts on behalf of another party with the explicit consent of the other party.   I don't think that's what he's talking about.
[22:31:35] <jhoyla> For those following along at home.
[22:31:40] <lpardue> I can stop if unhelpful
[22:31:48] <dkg> i find it helpful
[22:31:50] <Martin Thomson> keithmoore: excellent point.  This looks more like a relay.
[22:31:52] <ekr@jabber.org> keith: this is what we call proxy in the HTTP universe. Specifically HTTP CONNECT proxy
[22:31:59] <dkg> it lets me know what slide you're seeing, when my video is lagged
[22:32:06] <keithmoore> lpardue: I think it's very helpful, especially for those reading the jabber log and slides at a later time
[22:32:16] <Jonathan Lennox> It'll particularly be useful for correlating the Jabber log and the WebEx recording later.
[22:32:38] <lpardue> I had major issues with presenter's slides failing to update in an earlier webex. I'll continue based on feedback ^^
[22:32:41] <Magnus Westerlund> @ekr you may actually not need to tell anything. It can talk about packets only. Also path information can be provided that flows proxy to client.
[22:32:53] <ekr@jabber.org> In which case it can lie :)
[22:32:55] <keithmoore> ekr: but even HTTP CONNECT is acting as a proxy in the traditional sense - explicitly on behalf of the client - right?
[22:33:07] <ekr@jabber.org> keithmoore: that's what I take this to be. This is basically UDP CONNECT
[22:33:16] <ekr@jabber.org> Or at least I wish it were
[22:33:17] <spencerdawkins> That is an interesting question about the use of whatever we're calling this as a policy enforcement point ...
[22:33:29] mit-hat@jabber.hot-chilli.net joins the room
[22:33:38] mit-hat@jabber.hot-chilli.net leaves the room
[22:34:01] <jhoyla> Can we RetCon the agenda bash, to put the use cases before this presentation?
[22:34:03] Eric Kinnear joins the room
[22:34:06] <keithmoore> ekr: It may be that some of the examples he cited threw me off.  
[22:34:09] <ekr@jabber.org> Without a time machine
[22:34:19] merm leaves the room: Disconnected: closed
[22:34:21] <Magnus Westerlund> @ekr, any on path node can lie. However, this is a node you selected to use and which has an identity.
[22:34:35] Satoru Kanno joins the room
[22:34:54] merm joins the room
[22:34:55] <ekr@jabber.org> Magnus: well, generally, we don't allow people to lie with QUIC
[22:35:06] <ekr@jabber.org> because we just ignore what on-path nodes say
[22:35:32] <Mirja> a masque server is an endpoint of the outer quic connection
[22:35:49] <ekr@jabber.org> Mirja: yes, that's what I'm objecting to
[22:36:17] <Mirja> what are you objecting to exactly?
[22:36:50] <ekr@jabber.org> I don't think we should build a system in which we encourage nodes which are topologically intermediate to inject meta-information to the client.
[22:37:05] Jana Iyengar joins the room
[22:37:29] <Christian Huitema> Yep. If we do quic in quic, the inner quic has end to end encryption.
[22:37:30] <Mirja> why not if you decided to talk to that node, it might as well tell you smething you want to know
[22:37:32] <tfpauly> Ekr, does it make a difference if the client specifically chose to use that endpoint?
[22:37:33] <ekr@jabber.org> For the same reason that we don't allow on-path nodes to inject meta-information about QUIC connections
[22:37:35] <mnot> It usually pays to just make sure you use consistent terms; e.g., _masque proxy_ rather than just _proxy_.
[22:37:43] <Bernard Aboba> To EKR's point - does this "proxy" do things like caching resources?
[22:37:45] <keithmoore> ekr: concur.   but if this were like another SOCKS but maybe more versatile/efficient, with the proxy explicitly specified by the client and verified, I'm not sure that would be a Bad Thing.
[22:37:47] <ekr@jabber.org> tfpauly: no, not really, because there are general equilibrium effects
[22:37:48] <tfpauly> It’s not about on-path injection as much as using something as a tunnel
[22:37:48] <lpardue> s15 - use cases & rquirements
[22:37:52] behcet joins the room
[22:37:55] Eric Kinnear leaves the room
[22:38:01] <jhoyla> If you had a MASQUE connection, a, inside a different MASQUE connection, b, then can b lie to you about anything?
[22:38:05] <lpardue> s16
[22:38:34] <lpardue> @jhoyla, lie to whom?
[22:38:47] <dschinazi@jab.im> I probably should have been clearer: MASQUE shouldn't be able to lie to you, you still use TLS or QUIC end-to-end to ensure the MASQUE server can't mess with your traffic
[22:39:09] <jhoyla> @lpardue Can the MASQUE endpoint lie to the client about routing?
[22:39:10] <ek.ietf> the source IP address the server1/2 sees is that of the MASQUE server?
[22:39:18] <ekr@jabber.org> dschinazi: yes, I got that. What I'm saying is that we shouldn't design this with signals from the MASQUE server to the client about stuff
[22:39:46] <ek.ietf> just answered, I think
[22:39:46] <kaduk@jabber.org/barnowl> I think the fallout from PHB's "crypto is a blanke that's too short"
analogy applies here, and we should talk about what classes of
information are protected by which crypto, and make sure that lines up
with the information model we want.
[22:39:53] <hta> but signals from the client to the MASQUE server are OK?
[22:39:54] <lpardue> s17
[22:40:13] <Martin Thomson> Why would I not stick DoH over this?
[22:40:13] <ekr@jabber.org> hta: yes, because those are instructions
[22:40:16] <jhoyla> @ekr Doesn't QUIC by design mean that the client and proxy agree on some information?
[22:40:33] <jhoyla> Which arguably constitute a signal.
[22:40:43] Eric Kinnear joins the room
[22:40:56] <dschinazi@jab.im> @MT: the draft currently has a DoH MASQUE application to do exactly that
[22:41:02] <ekr@jabber.org> jhoyla:that seems like semantics
[22:41:13] Eric Kinnear leaves the room
[22:41:17] <lpardue> s18
[22:41:38] <Martin Thomson> dschinazi@jab.im: I know.  But how is that different than just making a DoH request using a connection (TCP/QUIC) to your DoH server of choice?
[22:41:50] <Martin Thomson> That suggests a DoH server of the MASQUE server's choice.
[22:42:04] <sftcd> @ekr: maybe an example of a dodgy-signal would help? e.g. the masque-proxy will select an ALPN or other TLS parameters which is presumably ok
[22:42:04] <tfpauly> Or just a DoH connection proxied through MASQUE
[22:42:06] <jhoyla> @ekr It seems hard to write a reasonable requirement into the spec without getting tangled in those semantics.
[22:42:31] <lpardue> s19 (although it is unlabelled)
[22:42:31] <Christian Huitema> In parcatice it does make sense to resolve the name from the proxy location.
[22:42:32] <ekr@jabber.org> sftcd: these packets were dropped
[22:42:33] <Martin Thomson> I mean, you might as well just have https://masque.example/dns-query served from the server.
[22:42:36] <ekr@jabber.org> when they were not
[22:42:44] <Jonathan Lennox> https://www.pokemon.com/us/pokedex/cubone ?
[22:42:47] <Ben Schwartz> Martin: That's exactly the idea.
[22:42:51] <jhoyla> For example, if someone makes a QUIC extension, does that count as a separate signal?
[22:43:08] <ekr@jabber.org> Well, that's just "co-located DoH server"
[22:43:16] <ekr@jabber.org> which seems fine
[22:43:25] <Ben Schwartz> co-located, shared authorization, and an in-band discovery mechanism
[22:43:26] <Martin Thomson> Ben Schwartz: then that doesn't require integration with any framework.  It's what ekr said: colocated
[22:43:31] <mpiraux> A video presenting draft-piraux-quic-tunnel in more details is available at https://www.youtube.com/watch?v=MYogYjp57Fw
[22:43:48] <Christian Huitema> Colocated would require 2 quic connections in parallel?
[22:43:49] <Ben Schwartz> How do you learn the URI template?  MASQUE needs to provide a mechanism.
[22:43:54] <Martin Thomson> I'm sure that ADD would be very happy to take this contribution.
[22:44:26] Glen (AMS IT) leaves the room
[22:44:30] xp29srs leaves the room
[22:44:34] <ekr@jabber.org> Christian: I don't think that would be needed, no
[22:44:36] <Ben Schwartz> Christian: No, if it's the same HTTPS origin it can be a single QUIC association.
[22:44:49] <dschinazi@jab.im> The idea there is that if you're a client who's choosing to use MASQUE as your VPN server (as you would use IKEv2/IPsec or OpenVPN today), you can choose to let the MASQUE server tell you that it has a DoH URI
[22:44:52] <lpardue> s20 (unlabeled) -  "QBONE Details - What We Built"
[22:44:56] <Christian Huitema> Then I think that's pretty much the obvious solution.
[22:45:06] <sftcd> @ekr: so would it make sense to you to say that the masque-proxy can send signals about the TLS-session between client and proxy but not about client to others?
[22:45:22] <ekr@jabber.org> sftcd:no, I'm objecting to the signals at all
[22:46:15] <sftcd> ok, but it's unclear to me how to distinguish between e.g. proxy-selected ciphersuite/alpn and what's-a-signal
[22:46:34] <ekr@jabber.org> sftcd: I don't really find it that difficult, but this isn't the forum
[22:46:59] <lpardue> s21
[22:47:23] <sftcd> well, this (BoF->WG) wants to be the forum:-)
[22:47:34] <ekr@jabber.org> yes, I'm saying Jabber is not the forum
[22:47:35] <sftcd> but sure doesn't need to be done and dusted today
[22:48:22] <Martin Thomson> To be clear: HTTP/3 already provides HTTP CONNECT.
[22:48:24] <carrickdb@jabber.hot-chilli.net> Dumb question: If MASQUE is for QUIC proxying, why is it necessary to do anything beyond stripping off the outer QUIC packet?
[22:48:30] <cvmiller> Is there a non-address translation mode?
[22:48:32] <lpardue> s22
[22:48:51] <ekr@jabber.org> carrickdb: that's my argument too. David wants to compress the CID
[22:48:54] <dschinazi@jab.im> @Carrick to save bytes per packet you can elide redundant info
[22:49:03] <ekr@jabber.org> But to be clear, I think this is bad :)
[22:49:19] <carrickdb@jabber.hot-chilli.net> How many bytes does that save?
[22:49:26] <carrickdb@jabber.hot-chilli.net> Also, thanks for the answer :)
[22:49:30] <cvmiller> I thought the point of IPv6 was to finally allow us to move away from NAT
[22:49:42] <dschinazi@jab.im> IP address (16) + port (2) + CID (8)
[22:49:56] <dkg> but that  can't be stripped from everyone packet, right?
[22:50:02] <carrickdb@jabber.hot-chilli.net> Is that worth the additional complexity?
[22:50:04] <ekr@jabber.org> The IP address isn't needed if you do UDP CONNECT
[22:50:08] <dkg> so it's not a uniform win for the MTU
[22:50:19] <ekr@jabber.org> nor is the port
[22:50:22] <ekr@jabber.org> So you really only get the CID
[22:50:24] <dkg> s/everyone/every/
[22:50:28] <ekr@jabber.org> There is a lot of prior art here (TURN)
[22:51:00] <Ben Schwartz> cvmiller: In IPv6 mode, I think we might be able to avoid NAT.
[22:51:03] <dschinazi@jab.im> Perhaps we can go into detail on the protocol wire format after the BoF? Today's goal is seeing whether we want to work on this :-)
[22:51:17] <ekr@jabber.org> dschinazi: we could if this weren'tbaked into the charter
[22:51:27] <cvmiller> @ben, thanks, that would be helpful
[22:51:44] <Jonathan Lennox> Need to figure out whether "TURN over QUIC"  or "SOCKS6 over QUIC" solve the use cases
[22:51:52] <spencerdawkins> Yeah, we're talking about the THIS that we might or might not want to work on ...
[22:51:53] <Magnus Westerlund> I think the simiarlity to TURN is correct. One move the proxy to server address into a channel ID on the inside of client to proxy QUIC tunnel.
[22:52:07] <Mirja> Nat is optional is the proxy is on path
[22:52:58] <lpardue> I'd also like to maintain the concepts of HTTP proxying for H3
[22:53:04] <lpardue> s23
[22:53:06] <Mirja> but some people actually want to preserve the privacy benefit you also get as a side effect
[22:53:11] <Mirja> of NAT
[22:53:34] <cvmiller> @mirja yes, optional is good
[22:53:40] <lpardue> s24
[22:53:43] <dschinazi@jab.im> One of the benefits of this model is that it allows you to build two different applications, one with NAT and one without based on your use-case
[22:53:44] <Mike Bishop> Where is the current charter text?
[22:53:45] <keithmoore> Mirja: IMO that privacy "benefit" is an illusion
[22:53:56] mglt joins the room
[22:54:05] <lpardue> s22
[22:54:07] <ek.ietf> @keithmoore: +1
[22:54:38] <keithmoore> dschinazi: why is that a benefit?   I must be missing something.
[22:55:18] Eric Kinnear joins the room
[22:55:19] <dschinazi@jab.im> If you have a VPN server you trust, it can allow you to hide where in the world your phone is from the web servers you talk to
[22:55:23] <ekr@jabber.org> keith: I don't understand your argument here. It's a privacy benefit to hide your IP from the origin server because that is a tracking vector. This is a major purpose for VPNs
[22:56:39] <ek.ietf> it's one things to use and IP address assigned by the proxy/vpn server;it's a separate matter whether the client knows what that IP address is
[22:56:43] <ek.ietf> @ekr
[22:56:51] <Mike Bishop> Ah:  https://github.com/chris-wood/ietf-masque/blob/master/README.md
[22:56:53] <ekr@jabber.org> ek: now you really lost me
[22:56:53] <keithmoore> ekr, dschinazi: that much I get.   I'm not following why having two different applications is a good idea.
[22:57:04] <ekr@jabber.org> Oh, I don't care about two different applications
[22:57:12] <ekr@jabber.org> Actually, I negatively want that :)
[22:57:13] <ek.ietf> I was trying to separate NAT into two separate issues
[22:57:15] <spencerdawkins> Please tell me we don't have to solve the multi-listener traffic analysis problem in this working group. Yes, we need to solve it, but ...
[22:57:38] <Bernard Aboba> The threat model probably isn't the same for every potential MASQUE application.  So threat analysis may need to be application-speicifc.
[22:57:39] <cvmiller> Anytime NAT is involved, then the question of Lawful Intercept appears, and the logging requirements which can get ornerous
[22:58:17] <mnot> Can someone post a link to the most current charter proposal?
[22:58:28] <Martin Thomson> I assume that we are also talking about being willing to accept PMTU constraints.
[22:58:32] <ekr@jabber.org> https://github.com/chris-wood/ietf-masque/blob/master/README.md
[22:58:40] <mnot> ta
[22:59:46] <sftcd> so ekr, that charter text doesn't mention your issue about proxy->client signals, right?
[23:00:05] <ekr@jabber.org> It just doesn't spec them
[23:00:11] <ekr@jabber.org> So I am happy to oppose them when proposed :)
[23:00:25] <sureshk@jabber.org> :-)
[23:00:28] <sftcd> right, that text sets up those bun fights for later
[23:00:35] leifj leaves the room
[23:00:42] Eric Kinnear leaves the room
[23:00:51] stf leaves the room
[23:00:51] <Martin Thomson> we could take a dependency on ECHO, but that means taking a dependency on something that might not be widely deployed
[23:00:59] <Bernard Aboba> Looking at the Charter it is about a framework... but not clear where individual use cases (some involving work not yet chartered) will be handled.
[23:01:05] <tfpauly> I did have one more question in the queue..
[23:01:08] <dschinazi@jab.im> Ah yes, also a dependency on HTTP/3
[23:01:08] <sftcd> too early for a dependency on ECHO
[23:01:09] <lpardue> s25 - Charter discussion
[23:01:24] <Martin Thomson> deploying ECHO on a host that has a single associated domain name might be a signal we don't want to create
[23:01:25] <sftcd> maybe before this gets done perhaps you'd depend on ECHO but not yet
[23:01:32] stf joins the room
[23:01:37] behcet leaves the room
[23:01:52] Eric Kinnear joins the room
[23:02:00] <dschinazi@jab.im> @sftcd yes I've explicitly avoided a dependency on ESNI/ECHO until it gets closer to ready
[23:02:10] <ekr@jabber.org> I don't think ESNI/ECHO is necessary here.
[23:02:19] <watson17> Obligatory: https://xkcd.com/927/
[23:02:23] <dschinazi@jab.im> (And even when ESNI/ECHO ships I'm not sure we should depend on it at this time)
[23:02:34] Eric Kinnear leaves the room
[23:02:35] <Christian Huitema> I like to see ESNI/ECHO used everywhere, but I may biased...
[23:02:35] <sftcd> @MT: maybe, I'd like ECHO to be useful for some hosts that have 3 names though
[23:02:46] <ekr@jabber.org> watson: indeed. I think the major advantage here is we know peope want to deploy QUIC and may not want to deploy TURN. Otherwise, it's a different spelling of TURN over DTLS
[23:02:51] <lpardue> I also don't see there being a dep on ECHO
[23:02:55] <lpardue> s28
[23:02:57] <achernya> I think ESNI helps, but doesn't change the desired properties here much
[23:03:12] <Martin Thomson> sftcd: absolutely.  At the point where ECHO is more widely deployed, it won't look so odd to deploy it.
[23:03:20] Eric Kinnear joins the room
[23:03:41] jpc leaves the room
[23:04:35] <cabo> 147 in Webex, 110 in Etherpad
[23:04:55] <cabo> 110 in Etherpad blue sheet, 62 in Etherpad
[23:05:40] <Martin Thomson> I'm getting periodic, short dropouts from Chris.  Is anyone else?
[23:05:47] <ekr@jabber.org> Hmm.. No
[23:05:49] <mbaushke@jabber.hot-chilli.net> i am also hearing dropouts
[23:05:50] <ek.ietf> I am
[23:05:54] <ekr@jabber.org> But I have been getting dropouts from others
[23:05:57] <StephenBotzko> me too.
[23:06:03] <ekr@jabber.org> So maybe I am just inattentive
[23:06:04] <Mirja> yes, I get some drop outs from chris but only few
[23:06:19] <Martin Thomson> Yeah, it's only occasional.  At least it isn't only me.
[23:06:29] <Martin Thomson> No need to reload, which takes forever.
[23:06:45] <mbaushke@jabber.hot-chilli.net> only occasional for me as well.
[23:07:12] <jhoyla> You can reload in another window, wait for connection, then close the first window.
[23:07:55] <lpardue> in counterpoint to Tommy, some of the proposed use cases have their own extant discovery mechanisms. Therefore I don't think we want to take on the work to specify those things in IETF
[23:08:32] <tfpauly> That’s fair, but even if we have existing mechanisms, do we need a standard URI format or something at least to “name” a specific MASQUE server?
[23:08:36] <Martin Thomson> mnot is dropping out too :(
[23:08:50] <dschinazi@jab.im> Today a MASQUE server is identified as a hostname and port
[23:09:02] <dschinazi@jab.im> But based on some feedback we could identify it as a URL
[23:09:07] <adam> Martin: I'm only getting some light crackling
[23:09:16] <Magnus Westerlund> Regarding service discovery: But, the very most basic part is to know an identity and a location to talk the framework protocol to determine supported functionalities/services.
[23:09:16] <adam> martin: Nothing I would call drop-outs
[23:09:33] <msk> same here
[23:09:35] <Jonathan Lennox> I'm getting light crackling but also clear speed-up (i.e. jitter buffer shrinkage)
[23:09:36] <lpardue> if the use of HTTP/3 sticks, the identity seems obvious
[23:10:45] merm leaves the room: Disconnected: closed
[23:10:53] xp29srs joins the room
[23:10:55] merm joins the room
[23:12:51] <Martin Thomson> wherefore art thou Mirja?
[23:13:04] <Martin Thomson> I lost audio
[23:13:16] <Martin Thomson> aaand it's back
[23:13:24] <ek.ietf> NBN?
[23:13:29] <sureshk@jabber.org> @mt: I heard her all the way through
[23:13:33] <Mike Bishop> I think David and Mark are both semi-correct.  Unreliable CONNECT definitely provides a substrate that you could use to meet these requirements, but you'd have to define how to delineate packets over that.
[23:13:50] <Ted.h> Ask SIP how reusing parts of HTTP worked out for them.
[23:14:07] <tfpauly> I do think we need to iron out that before a charter
[23:14:10] <tfpauly> +1 to Mark
[23:14:39] <Cullen Jennings> New protocol called HTTP-CONNECT
[23:14:44] <carrickdb@jabber.hot-chilli.net> +1 to mark from me too
[23:14:46] <lpardue> how about, an extensible extension to an existing application protocol over QUIC?
[23:14:50] <Martin Thomson> If you use the same ALPN label as HTTP/3, then it's HTTP/3
[23:14:58] <Ben Schwartz> The odds of HTTP defining a method to emit an arbitrary IP fragment in some arbitrary direction seems ... low.
[23:15:06] <carrickdb@jabber.hot-chilli.net> This seems like compressed QUIC rather than something just on top of QUIC
[23:15:06] <Mike Bishop> I think a dependency on ECHO is entirely appropriate -- make an unremarkable HTTP/3 connection to the server, get the ECHO keys, then reconnect with the ALPN of the MASQUE protocol concealed.
[23:15:09] <Christian Huitema> It does feel like an application on top of H3.
[23:15:14] <ekr@jabber.org> lpardue, how about an extension to an extensible extension to an existing application protocol which extends quic
[23:15:44] <lpardue> @ekr now you're cooking with MASQUE
[23:15:45] <Ted.h> q discipline seems to be breaking down...
[23:15:48] <ekr@jabber.org> indeed
[23:15:57] <ekr@jabber.org> who was that?
[23:16:06] Steve Todd leaves the room
[23:16:11] <ekr@jabber.org> Alexey?
[23:16:13] <keithmoore> To me it sounds like there needs to be a clear separation between this and HTTP/3.   Such that nobody gets confused about which layer is which.
[23:16:15] <tfpauly> That was Suresh
[23:16:16] <Christian Huitema> I mean, it is either masque over quic or masque over h3. If masque over quic, then the alpn would be something like "moq".
[23:16:20] <Alexey Melnikov> depending on whether this is going to be a new protocol over QUIC or HTTP/3 extension, WEBTRANS might need to be listed as a WG to cooperate with
[23:16:22] <ekr@jabber.org> moqqqqq
[23:16:58] <Zaheduzzaman Sarker> now Martin is dropping a lot for me ...
[23:16:59] <Christian Huitema> moque
[23:17:03] <watson17> i thought quic could use different streams for different things
[23:17:26] <Alexey Melnikov> ekr@jabber.org: I didn't say anything on audio
[23:17:45] merm leaves the room: Disconnected: closed
[23:17:45] <Mike Bishop> @watson17, QUIC is multi-streamed, but you negotiate a single ALPN during the handshake.  That application protocol defines the use of all streams.
[23:17:51] <mnot> I will point out that the NBN is working just fine for me...
[23:17:58] <Christian Huitema> We don't have that yet in quic. Yes it would be cool to split the streams between different apps, but that's an new can of worms
[23:18:08] <Martin Thomson> I will try again later then
[23:18:12] <watson17> i thought that's partof what masque wants to lift
[23:18:13] merm joins the room
[23:18:44] <Mike Bishop> I haven't looked at their proposed wire format, so perhaps.
[23:19:09] <lpardue> I disagree, we built H3 with extension mechanisms and have H3 datagram in the wings. Do you want to say those cannot be used?
[23:19:34] <Martin Thomson> OK, this is clearly at my end
[23:20:05] <afrind> H3 defines the use of all client initiated bidi streams.  If you negotiate MASQUE over H3, how does the endpoint distinguish the non-h3 streams?
[23:20:16] <Mike Bishop> You can totally define extensions to HTTP/3, yes.  Pick your unidirectional stream IDs, or define how Datagrams get used, or define unreliable CONNECT.
[23:21:04] <lpardue> just like websockets over H2 can be repurposed
[23:21:24] <afrind> So each MASQUE stream has to start with an H3 HEADERS block with extended CONNECT?
[23:21:52] <Mike Bishop> Perhaps.  Or maybe client requsts a channel using a new uni stream ID, and the server responds by opening a server-initiated bidirectional stream for that flow.
[23:22:12] <Ted.h> @spencer If this were an in-person bof, I'd be offering a beer to someone who asks about multicast over MASQUE.
[23:22:21] <lpardue> +1 to Mike Bishop
[23:22:23] <Ted.h> @spencer but it seems cruel to take q time for it.
[23:22:51] <ekr@jabber.org> I'm happy to litigate this charter text later
[23:22:55] <lpardue> I think you'd want AMT over MASQUE tbh Ted
[23:22:56] <ekr@jabber.org> I just wanted to flag it
[23:23:04] <sureshk@jabber.org> Thanks ekr!
[23:23:05] <spencerdawkins> @ted.h - and sadly, I don't drink beer, so that's only slightly less tempting ;-)
[23:23:24] <Ted.h> @spencer  Calming white tea?
[23:23:53] <Ted.h> @lpardue or even ATM
[23:24:54] xp29srs leaves the room
[23:24:58] <keithmoore> I guess I don't understand why you'd want to restrict this to specific protocols.   If you do that someone will just need to come along later and extend this or define another mechanism for new protocols.     Why isn't this a general-purpose tunneling mechanism?
[23:25:14] <ekr@jabber.org> keith: who are you talking to?
[23:25:23] <keithmoore> the jabber chat
[23:25:38] <ekr@jabber.org> I think this is a general-purpose tunnelling mechanism
[23:25:49] <keithmoore> agree with the current voice speaker.
[23:25:52] <Martin Thomson> But Ben Schwartz, this isn't that.  So maybe you should generate a proposal.
[23:26:20] <ekr@jabber.org> Ben: I actually am not a fan of that because in many cases the proxy wants the packets to appear to originate from it, so why are we carrying the IP header?
[23:26:27] <Mirja> I don't think there is a forwarding function in webtrans, no?
[23:26:28] joehall joins the room
[23:26:43] <lpardue> I want a HTTPs proxy solution for HTTP/3, and raw IP packets via a proxy is not the same as today's solutions
[23:26:44] <ekr@jabber.org> Or rather, I'm fine with IP, but I don't want to *just* have IP
[23:27:28] <mnot> "doing it from javascript" is an important requirement that places a number of constraints on the solution; would be good to be explicit about whether it's in-scope.
[23:27:46] <keithmoore> one thing I'd like to avoid is applications having to be explicitly aware of this - don't want to add more complexity to applications.
[23:27:52] <Jonathan Lennox> There are plenty of Javascript-based VMs that could use an IP connection…
[23:27:57] <dschinazi@jab.im> JavaScript is in-scope for WEBTRANS and out-of-scope for (my view of) MASQUE
[23:28:24] <adam> mnot -- I'll draw attention to the DOH approach, which was that it would not make provisions to enable javascript to use the protocol, but neither would it take explicit countermeasures to prevent it.
[23:28:28] <dschinazi@jab.im> @keith this should be transparent to applications just like a VPN is today
[23:28:28] <ekr@jabber.org> Well, wouldn't MASQUE just be ana pplication taht used WebTransport
[23:28:28] <keithmoore> there's a separate set of considerations for: what subset of this should a JavaScript program be able to use?
[23:28:37] <ekr@jabber.org> like "here is where the datagrams go"
[23:28:51] <ekr@jabber.org> BTW, I posted my point about the charter to the list.
[23:28:53] <keithmoore> dschinazi: agree
[23:29:13] <ekr@jabber.org> dschinazi: I'm surprised to hear you say that, because that's not how (say) FPN works
[23:29:17] <kaduk@jabber.org/barnowl> Ted hates MT's audio, I guess?
[23:29:20] <Magnus Westerlund> And this is going over way to many layers for what I see as being important here. The main function is packet forwarding. If that function requires a very large stack I worry about the performance and footprint, even if there is easy re-use of a lot of code.
[23:29:33] <Martin Thomson> Jana Iyengar: you were resizing the window, or at least it was manifesting as that
[23:29:37] <keithmoore> Magnus: +1
[23:30:14] <adam> Magnus Westerlund: What, you don't want to see SCTP over UDP over IP over QUIC over UDP WebRTC traffic?
[23:30:18] <Martin Thomson> Magnus Westerlund: there is a version of this that doesn't traverse the big stack, except for the purposes of signaling.  That's not in the drafts, of course.
[23:30:26] Atarashi Yoshifumi leaves the room
[23:31:02] <Zaheduzzaman Sarker> what is SCTP ? :-)
[23:31:55] <lpardue> super-califragilistic-transport-protocolatrocious
[23:32:12] <Zaheduzzaman Sarker> :-D
[23:32:51] <Magnus Westerlund> @Martin and that I think is okayish.
[23:32:53] nemo joins the room
[23:33:02] nemo leaves the room
[23:33:09] nemo joins the room
[23:33:30] stf leaves the room
[23:35:04] <Ted.h> Sorry I was long winded.  To reply to Mirja here, I don' see the advantage of trying to build a generic VPN tool, a proxy DNS service, and an HTTPS proxyc into a single mechanism.  If you truly see this as a relay, then *all of the other semantics* drop.  Making the proxy understand all of those different semantics either makes it a very complicated network element or  forces you to do capabilities exchange/discovery even when you know you have MASQUE service available.
[23:35:26] <keithmoore> Ted.h: +1
[23:35:39] <Ben Schwartz> Ted: It's basically a performance optimization.  Why use IP forwarding when you can use HTTP CONNECT?
[23:36:06] <hta> so is the proxy going to police the stuff it passes,or not?
[23:36:08] <Ben Schwartz> Also, IP forwarding is inconvenient for applications that are using the kernel's TCP stack.
[23:36:12] <tfpauly> +1 to ted. If the same mechanism happens to help all those use cases, that’s great; but if each has separate knobs then they’re not really unified.
[23:36:17] mglt@xmpp.zone joins the room
[23:36:32] <Mirja> my assumption is that you want to use one single proxy connection for different forwarding services which would already require some extend of negotiation
[23:36:42] <Magnus Westerlund> For discovery we do have a draft that discuss options that would be reasonable to use: https://datatracker.ietf.org/doc/draft-kuehlewind-quic-proxy-discovery/
[23:36:51] <keithmoore> I could sort of make a case for two services: IP packet forwarding (with header compression) + stream forwarding.   But it's a slippery slope from 2 to N services.
[23:37:03] <Ted.h> @Ben  If you are trying to hide this within HTTP traffic, then using HTTP connect for IP forwarding is a privacy/security functionality.  But the obvious reason not to use HTTP connect is the semantics of HTTP are significantly more complex than a relay', so you are inheriting a big stack to do a small thing.
[23:37:16] <Alexey Melnikov> To echo what Spencer just said: something like MASQUE would be good to do, whether or not it is related to WEBTRANS
[23:37:25] <Mirja> yes negotiation is more complex than no negotiation but it also more flexible and I don't agree that it makes it very complicted; we know how to design these kind of negotiation/control protocols
[23:37:45] <Martin Thomson> Compression is not a thing here.
[23:38:03] <Jonathan Lennox> I have that this session ends at 17:10 PDT, not 16:40
[23:38:20] <ekr@jabber.org> yeah, they want to do the bof questions
[23:38:31] <sftcd> the chairs may be expecting people to quibble about bof questions:-)
[23:39:18] <keithmoore> Mirja: IMO any kind of interaction between an application client and the MASQUE server is problematic and very nearly a showstopper.
[23:39:56] <Mirja> which kind of interaction? you need at least tell the masque server where to forward you traffic
[23:39:56] <Eric Kinnear> from Ian Swett to Everyone:    4:39  PM
3 comments I wanted to add: 1) We should pursue this work, 2) We need to determine whether it's over QUIC or over HTTP/3 before creating the WG 3) This work makes me think DATAGRAM may need to be in QUIC v1, which I wanted thoughts on.
[23:40:02] <watson17> what are the bof questions vs charter?
[23:40:06] <lpardue> thanks Eric
[23:40:12] <Martin Thomson> Does anyone actually *know* what WebTransport is at this point?
[23:40:17] <spencerdawkins> When I joined the IESG, I was amazed at how much of the conversation happened in the jabber room vs the voice conversations. We probably need the jabber log for this session to be part of the minutes - it's been non-stop.
[23:40:31] <keithmoore> Mirja: that's why I said application client.   application clients should not have to be aware of this at all.
[23:40:37] <achernya> Well, i wanted to say this live, but webex decided that I don't get to talk and froze
[23:40:50] <achernya> I think it's important to address the things that Mark Nottingham and EKR brought up w.r.t to h3
[23:41:06] <achernya> as far as I know, QBONE is the only non-HTTP use of QUIC out there, and there are a few intersting things that we learned
[23:41:22] <Mirja> @keithmoore: yes agreed the whole tunneling doesn't have be done by the application
[23:41:24] <achernya> 1. In order to do forwarding, we need MESSAGE/DATAGRAM frames. This makes the entire thing work at all
[23:41:34] <achernya> 2. In addition to the unreliable frames, you also need a reliable control channel
[23:41:49] <achernya> The reliable control channel can be any arbitrary protocol, but in the current draft, it's H3
[23:42:21] <achernya> I personally don't have strong feelings about what the first reliable stream that we negotiate the parameters over is. For QBONE it happens to be a simple request-response protocol using protobufs
[23:42:42] <keithmoore> Mirja: my specific concern (for the moment) is avoiding applications having to know about this.   and even if they merely benefit from explicit interaction with the MASQUE service, that will eventually become a necessity.
[23:43:32] <Mirja> it's entirely optional to interact with the masque server and it's probably more useful on a device level than application level
[23:43:52] <hta> nested congestion control is bad.
[23:44:21] <keithmoore> Mirja: "optional" sounds dangerous to me.   because it won't be optional forever, and it ends up adding complexity to every application that might need to operate over MASQUE
[23:44:26] <Magnus Westerlund> @keithmore masque applications is not your end-to-end application.
[23:44:29] <sftcd> people do like their transport theories don't they:-)
[23:44:33] <keithmoore> hta: +1
[23:45:06] <spencerdawkins> Stephen - the transport theories don't change. The SEC theories do :p
[23:45:12] <Martin Thomson> hta: is there a document that describes the badness?
[23:45:24] <keithmoore> Magnus: I would believe that if applications absolutely could not talk directly to a MASQUE server, but I'm not yet convinced.    Because I think there's nothing stopping an application from linking in a MASQUE stack as long as the app has permission to talk to that server.
[23:45:31] <Martin Thomson> because I don't think that this is a topic worth discussing with respect to the charter, but we all want to learn
[23:45:48] <hta> TCP over Wifi is a case of nested congestion control. Matt Mathis is much more eloquent than I am about it.
[23:46:13] <watson17> that's recovery! I think I was conflating them
[23:46:13] <Martin Thomson> hta: I don't want a *person*.  That doesn't scale.  Is there a document?
[23:46:22] <Eric Kinnear> I've seen it implied that in practice it's not in fact absolutely terrible, but probably better to take that up in some other venue
[23:46:23] <hta> I don'
[23:46:23] <sftcd> @harald: is it nested or nested-but-ignoring-one-another that's the badness?
[23:46:28] <watson17> although queuing signalling to the inner flow to back off is different
[23:46:28] <hta> I don't have a document.
[23:46:36] <Martin Thomson> bummer, thanks
[23:46:41] <hta> Sorry!
[23:46:45] <Magnus Westerlund> @keithmore yes, and application that like a specific masque service could definitly talk to it. Just trying to make sure that we are not missunderstanding the different meanings of applications here.
[23:47:03] <watson17> @sftcd: i've been told that it's because the inner stream doesn't get told it need to take less data
[23:47:10] <Ben Schwartz> mnot: OK, thanks.  (I remember your draft...)
[23:47:34] <keithmoore> Magnus: yes, it's difficult to talk about this without it being confusing.
[23:47:54] nemo leaves the room
[23:48:00] <hta> the typical case is that when the lower CC starts to run slower, the upper CC discovers that things are going bad and backs off - exactly at the time when the lower CC thinks that the congestion has cleared and loosens up. For instance.
[23:48:01] nemo joins the room
[23:48:03] <spencerdawkins> nested congestion control, nested pacing, etc. is a TSVWG or TSVAREA topic. It's been discussed a couple of times recently (like, TCP tunneling, maybe a year ago, plus or minus 1 IETF meeting)
[23:48:14] <sftcd> cullen's point is good: can the masque client be a mail server?
[23:48:23] <Jonathan Lennox> If the inner context acts like a router (queuing, tail drop, maybe even ecn or cddl) does it work then?
[23:48:36] <ekr@jabber.org> I had assumed that we presently did not expect to run servers
[23:48:45] <carrickdb@jabber.hot-chilli.net> Can someone explain why you couldn't you have QUIC over QUIC? The payload would be the packet the proxy forwards.
[23:48:46] <sftcd> could be, fine question though
[23:48:47] <hta> jonathan: I don't regard drop-from-queue as congestion control.
[23:48:55] <keithmoore> Magnus: but I also think that we're inevitably going to have something like this, whether we want it or not, including the potential for each app to negotiate its own relationship with an external proxy.   so we might as well try to understand the hazards.
[23:49:00] <ekr@jabber.org> carrick: you can have quic over quic. It's just not specified yet
[23:49:02] <achernya> There's no specification for anything-over-QUIC over than h3
[23:49:10] <achernya> *other than, rather
[23:49:15] <Ted.h> @Martin I dropped Matt a note to ask for a citation; will forward to you if he has one that can be referenced.
[23:49:18] <carrickdb@jabber.hot-chilli.net> I see, thanks
[23:49:25] <Martin Thomson> Ted.h: appreciate it, thanks
[23:49:30] <spencerdawkins> That's the problem - there's not a generalized upper interface for QUIC.
[23:49:35] <lpardue> siduck is a specification
[23:49:43] <msk> interesting
[23:50:02] <lpardue> https://tools.ietf.org/html/draft-pardue-quic-siduck-00
[23:50:10] <Jonathan Lennox> How many of these specs are named after Pokemon?
[23:50:15] <lpardue> :)
[23:50:43] <Jonathan Lennox> Well, you shouldn't run out of names for a while at least
[23:50:50] <Eric Kinnear> Martin Thomson: https://tools.ietf.org/html/draft-pauly-tsvwg-tcp-encapsulation-00, quite a lot of roughness/work to be done there but there is some discussion of relevant bits
[23:50:52] <kaduk@jabber.org/barnowl> So I should go ask the TLS DEs to register a "quic" ALPN value and
then we are off to the races for QUIC-in-QUIC?
[23:51:05] <adam> I'm expecting a "Siduck siduck siduck" version of the "Chicken chicken chiken" paper now.
[23:51:06] <achernya> We had been working on QBONE for months before someone pointed out to me we had named it after a pokemon...
[23:51:30] <watson17> i thought it sounded familiar
[23:51:34] <mnot> I think nailing down the level(s) of abstraction you're forwarding in the charter is critical; otherwise, people are going to be working at cross purposes.
[23:51:53] <Eric Kinnear> +1 mnot
[23:52:22] <kaduk@jabber.org/barnowl> I wonder if the "slides resizing" is webex thinking it needs to reduce
bandwidth for the media stream
[23:52:53] <Jonathan Lennox> The thing is the Mac menu bar isn't as far as I can tell changing
[23:53:10] <Jonathan Lennox> I wonder if it's some sort of screen animation being sampled at a very low framerate
[23:53:27] <keithmoore> I don't think the scope is sufficiently well defined to charter yet.
[23:53:43] <Eric Kinnear> The zooming in/out? I assumed that was Jana switching windows by triggering expose, the blank space is all the other windows he has open
[23:53:55] <Bernard Aboba> I think that the scope *could* be well defined with some more work.
[23:54:05] <sftcd> fwiw, I'm supportive of this but sanguine that well-meaning participants could figure out what substrate(s) to use inside a WG (I don't object to that being done ahead of time either though); I do think it might be good to either resolve the proxy->client signals issue before starting or else be happy that it'll be an ongoing sequence of disagreements. I'd be willing to review stuff and would probably try use the output.
[23:54:16] <Martin Thomson> Eric Kinnear: I skimmed your draft, but that wasn't what I was looking for.  At least from what I could see.
[23:54:16] nemo leaves the room
[23:54:16] <keithmoore> Bernard: I'd like to believe that thats' true, but am unsure.  
[23:55:00] <lpardue> slide 29 - BoF questions
[23:55:04] <Pete Resnick> Can I suggest that the chairs state what they believe they've heard so far and ask for people who think the chairs got it wrong.
[23:55:11] <Eric Kinnear> mt: Cool cool, no worries
[23:55:27] sftcd bets a certain Pete Resnick thinks the chairs will/did get it wrong:-)
[23:55:31] nemo joins the room
[23:55:43] <Pete Resnick> Just looking to save time.
[23:55:56] <Pete Resnick> I suspect they know.
[23:56:10] <Martin Thomson> What is this q+? notation?
[23:56:15] <ekr@jabber.org> qqqqqq
[23:56:28] <Pete Resnick> RPN
[23:56:35] <Jonathan Lennox> Looks like PCRE syntax, but I don't know why you need that many q's.
[23:56:43] <Martin Thomson> I mean, it is a non-greedy regex match
[23:56:46] <mnot> "inside a quic association owned by h3" constrains things in a number of ways
[23:56:55] <kaduk@jabber.org/barnowl> ==mnot
[23:57:08] <lpardue> q+? returns a Result to caller
[23:57:09] <keithmoore> I seriously doubt it's a good idea to have this use HTTP3.   QUIC makes sense.   HTTP3 is adding a lot of additional complexity that seems like a distraction at best.
[23:57:11] <msk> +? = *
[23:57:26] <Martin Thomson> msk: not so
[23:57:38] <Martin Thomson> it's still at least one, but it only matches more than one if it has to
[23:57:45] <lpardue> IT is no more complex to use HTTP/3, when you are trying to tunnel HTTP/3
[23:57:46] <mnot> please go play with meetingbot-test@chat.mnot.net if you find q syntax interesting. I need testers.
[23:58:03] <ekr@jabber.org> So I think there's a clear cut between "outgoing associations" (clients for QUIC, TCP, UDP, ...) and "generic packet transport" (servers, IP)
[23:58:13] <Ted.h> IP over UDP over HTTP/3 over QUIC over UDP over IP seems like it's a bad MTU story, at the very least.
[23:58:25] <ekr@jabber.org> And the second one is a huge scope expansion from the first, as we learned with TURN
[23:58:36] <ekr@jabber.org> So my put would be that we scope it to just the "client" modes
[23:58:39] <Jonathan Lennox> Hopefully the WebTrans overhead ends up pretty minimal?
[23:58:42] <ekr@jabber.org> And then maybe expand it later
[23:58:42] <Jonathan Lennox> If we get it right?
[23:58:44] <spencerdawkins> Pete - I think going through the minutes and jabber logs will be a multi-hour activity ...
[23:59:17] <Bernard Aboba> I am not hearing Martin very well... hopefully someone can.
[23:59:21] <Mirja> I don't think anybody want X over H3 rather than using H3 semantics to "negotiate"
[23:59:24] <ekr@jabber.org> "We don't need a framework"
[23:59:36] <ekr@jabber.org> I want X over H3.
[23:59:40] <Pete Resnick> @spencer: Sure, but they surely have a sense of whether the scope is well-defined and well-understood from the previous discussion.
[23:59:43] <ekr@jabber.org> Because that'show H3 TCP CONNECT works
[23:59:58] <achernya> EKR< why do you want it to be over H3? What benefit is H3 getting you over running it over QUIC directly
[23:59:58] <Jonathan Lennox> Do you consider that to be how WebSockets works?