WebTransport/Meetings2023

From W3C Wiki


WebTransport Bi-weekly Virtual Meeting #80 early - May 7, 2024

WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m6a263598d572ab9d28d0e96df485d23d EARLY Meeting number (access code): 126 078 4125


Agenda

  • Item
  • Item
  • Item

Meeting records

Present:

  • Minutes
    • Meeting will be recorded and available [Link here] along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
    • Notes:
      • Item


WebTransport Bi-weekly Virtual Meeting #79 late - April 23, 2024

WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m5904c63dd34fc592c2376e313cf19520 LATE Meeting number (access code): 126 406 0454

Agenda

  • Issues
    • Relative send priority between datagrams and streams #451
    • Quality of a bandwidth estimate #559
    • Expose State internal slot #539
    • CSP policies for WebTransport? Discuss at next meeting #59
  • PRs
    • Support relative URLs. #599
    • Add protocols constructor argument to WebTransport #598
    • Remove one dependency on "Data Recvd" #580

Meeting records

Present: Will, JiB, Bernard, Eric, Nidhi.

  • Minutes
    • Meeting was recorded and is available here along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
  • General - Will reviewed the status of open issues. We have 37 open issues, of which 9 are allocated to the CR milestone. 4 of those are for discussion today and 5 are ready-for-PR.
  • Issues
    • Relative send priority between datagrams and streams #451 - Chrome and FF differ in prioritization. Desirable if all implementations behave similarly. Bernard - reason to put datagrams higher is that I would send command via datagrams. Eric - I would think streams would be used for that. You will end up in world where datagrams are sent faster than link can sustain. At one point we talking about treating datagrams as a “sendGroup”?JIB - yes, but we never created buckets because there is only one writer. Eric - 1) we want to avoid starvation of either and 2) what is most likely to result in someone writing robust code? Will - control channels will usually be streams. Bernard - not always, sometimes DG are used. JIB - does round robin imply more fairness? Eric - we don’t want to discourage people using streams. It’s OK to encourage people to think carefully about how they use datagrams. Eric - what does the UA do when it has to implement “must not starve”? JIB - FF is willing to change implementation. If datagrams have a lower priority, that encourages developers to use streams. If datagrams have a higher priority, dev baseline expectations of UDP are applicable , you can use all the streams you want without having it restrict your datagrams. If you are going to put a timer-based expiry on a datagram, you can’t have it sitting around. Conclusion, Will’s proposal is fine. Eric - in Safari we currently round-robin streams and DG participate in that. Would be willing to revise.
    • Quality of a bandwidth estimate #559 - Will, what degree of wrongness can we live with. JIB - can we just defer this? Bernard - if we see low delay CC coming in, then we’ll get future feedback. Eric - can apps probe and find it anyway? Yes. JIB - what if we had two numbers? Eric - we could give a range? Or we can describe what we see, such as largest flight sent. What will people use this for? Bernard - in moq, if send p frames first, window enlarges to where you can send the entire I frame. Eric - we can skew in two directions - we give you slow start or app limited, or we try to answer what the dev needs to know? Could have a simple Boolean that says is it bounded or not? It is most accurate when we bump against the ceiling. If I am latency sensitive, we already have RTT stats that you can watch. Two choices:
      • going in the direction of exposing all the details, e.g. multiplicative decrease, additive increase, slow start etc. good luck?)
      • expose a boolean that says have we hit the ceiling (super recently)?. Might take to IETF land at Vancouver. Meeting tending towards 2. We could add 1 later.
  • PRs
    • Support relative URLs. #599 - JIB prepared PR to add baseURL during construction. No objection or discussion. Merged.
    • Add protocols constructor argument to WebTransport #598 - Martin - can we drop the sub? Bernard - moq is looking for a means to specify the version of moqt that will be used. Nidhi - we should match IETF use of subprotocol. Eric - this is very similar to ALPN. We should match IETF for now. Nidhi - we need to make sure this is present in H2 and overview doc. Prefer it is in overview doc. @Nidhi - assigned to write issue. Eric offered to write the PR.
    • Remove one dependency on "Data Recvd" #580 - no movement.

WebTransport Bi-weekly Virtual Meeting #78 early - April 9, 2024


WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m6a263598d572ab9d28d0e96df485d23d EARLY Meeting number (access code): 126 078 4125


Agenda

  • General - note that we requested our TPAC meeting from 14:00 - 16:00 PST on Sept 24, 2024.
  • Issues
    • Quality of a bandwidth estimate #559
    • Expose State internal slot #539
    • Relative send priority between datagrams and streams #451
    • CSP policies for WebTransport? #59
  • PRs
    • Remove one dependency on "Data Recvd" #580
    • Add protocols constructor argument to WebTransport #598

Meeting records

Present: Will, JIB, Lucas, Randell, Victor

  • Minutes
    • Meeting was recorded and is available here along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
    • Notes:
      • General - note that we requested our TPAC meeting from 14:00 - 16:00 PST on Sept 24, 2024.
      • Issues
        • Quality of a bandwidth estimate #559 - discussion came down to data-limited or not. JIB proposed API. Victor - data limited at which point in time? Will - 10min or 2s ago? Lucas - too many weird things that would need you to test the truthiness of the statement. Slow start and steady state seems unrelated to are you in slow start? JIB - would it be useful to expose time duration. Victor will take another look at the issue.
        • Relative send priority between datagrams and streams #451 - JIB, between stream sendGroups, sending is fair. Are datagrams a single silo? Must either come first, last or somewhere in the middle. Chrome and FF prioritize datagrams over streams. Will - can we just set that as , Lucas - RFC9218 recommends avoid starvation. Non-incremental streams should not be starved. Be wary of trying to be too specific. Maybe SHOULD not versus MUST NOT starve. Randell, looking at FF, appears to let datagrams be starved. Datagrams cannot be split, whereas Streams can be sliced as necessary. Randell - best if implementations were aligned. Could be first, last or round-robin, need to choose and agree. Lucas - hard to test this, but possible. Randell - we should pick what is best for apps overall, not what is easily testable. Randell - we would change if necessary. Victor - can we discuss this when Eric is present?
        • CSP policies for WebTransport? #59 - can we use connect-src ‘certificate-hash’ ? Is this a security issue?
      • PRs
        • Remove one dependency on "Data Recvd" #580 - still waiting on IETF.
        • Add protocols constructor argument to WebTransport #598 - subprotocols only defined for HTTP/3? JIB - reviewed. Will - is there preference for the order of subprotocols specified? Lucas - we might need to make clear preference. @Will to add comment to PR. Victor - we should call subprotocols and not protocols.

WebTransport Bi-weekly Virtual Meeting #77 late - March 26, 2024

WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m5904c63dd34fc592c2376e313cf19520 LATE Meeting number (access code): 126 406 0454

Agenda

  • Issues
    • Relative send priority between datagrams and streams #451
    • Quality of a bandwidth estimate #559
    • CSP policies for WebTransport? #59
    • Expose State internal slot #539
    • WPT tests are needed for serverCertificateHash feature #589
    • Should the constructor take http3Only or something more transport agnostic? #561
    • WebTransport API and ManagedMediaSource API #522
    • expose a TLS Keying Material Exporter / unique value for the TLS session #411
  • PRs
    • Update normative RFC references #594
    • Remove one dependency on "Data Recvd" #580

Meeting records

Present: Will, Javier, JIB, Victor, Martin (late), Eric, Nidhi, Bernard, Martin.


  • Minutes
    • Meeting was recorded and is available here along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
  • Issues
    • Relative send priority between datagrams and streams #451 - Will summarized. JIB - only thing that would be testable would be that datagrams should not starve streams and vice-versa. Proposed some language. What does fairness mean without weights? Martin - what you’ve suggested here is difficult to implement and test. Bernard - can we restrict BW in WPT tests? Chrome implementation is datagram has higher priority over everything. Will - what does FF do? Bernard - it’s to avoid complete starvation. Keep on talking.
    • WPT tests are needed for serverCertificateHash feature #589 - Javier, working on serverCertificateHash for FF, will improve browser interop if landed. The single test if for existence. I’d like to increase WPT coverage. Difficult to do, is there a way to support serverCertificateHash testing on WPT tests? Prob is 14-day expiration limit. Can we generate one per test run?RSA keys are forbidden, W3C would be willing to use something that is valid for Webtransport. Nidhi - we have an existing test for SCH, do you know how to generate a hash? Javier- yes, we can use this command ‘openssl x509 -fingerprint -sha256 -in ./tools/certs/web-platform.test.pem -noout’. Is this even possible or worth it? Eric - worth it? Yes. Possible? - different question. Victor - people for WT demos, generate certificate on the fly, JIB - what is next step? NIdhi - WPT people should help with this. Martin - can someone explain 14-day expiration? Javier - it’s in W3C spec. Martin - seems unnecessary. Victor - time limit prevents non-rotatable certs, otherwise people will hard code it. Javier- only way to do this is to generate certificates on the fly. Martin - that’s ATSA cert is quick to generate. Victor - you only have to rotate certificate, not the key. Nidhi - FWIW, we opened an issue with the WPT infra people here: https://github.com/web-platform-tests/wpt/issues/32463. Javier - we could also disable the check. Victor - sad if we turn it off. Javier - but we could turn it off for different tests. No need to test both at the same time. Martin - seems you have all the info you need. Javier - if it’s worth the effort, I will help coordinate it. May need some directions about best approach. Closed issue.
    • Should the constructor take http3Only or something more transport agnostic? #561 - no objection to closing. Any objection from Eric? Nidhi - did we file an issue against FETCH? We should keep same as fetch spec and then file against Fetch. Eric agreed to file. Could substitute with ‘requireUnreliable’.
  • PRs
    • Add note about retransmissions and send order #595 - reviewed. Retrans should be at a higher priority than new data. Victor - concerned. Feedback from MoQ is that you should not prioritize retransmissions. Eric - canceling a stream would have same effect as deprioritizing retransmissions. JIB - priority == sendOrder? Yes. Current behavior is safe default, (retrans always have higher priority), however apps will really want. Eric - Martin suggested time limits to prevent priority inversion. Feels weird to cross “gate” at which flow control credit has been granted. Victor - once you push data on wire, you have to commit to this until you reset the stream. Nidhi - for text, one option is remove 1st sentence. Group agreed. Also changed ‘advised’ to ‘encouraged’.
    • Remove one dependency on "Data Recvd" #580 - waiting for Victor’s PR at IETF - he needs to address review comments. After landed, we will update text in W3C text.

WebTransport Bi-weekly Virtual Meeting #76 early - March 12, 2024

WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m6a263598d572ab9d28d0e96df485d23d EARLY Meeting number (access code): 126 078 4125


Agenda

  • Issues
    • WPT tests are needed for serverCertificateHash feature #589
    • Should the constructor take http3Only or something more transport agnostic? #561
    • Quality of a bandwidth estimate #559
    • WebTransport API and ManagedMediaSource API #522
    • Relative send priority between datagrams and streams #451
    • expose a TLS Keying Material Exporter / unique value for the TLS session #411
    • CSP policies for WebTransport? #59
    • Expose State internal slot #539
  • PRs
    • Update normative RFC references #594
    • Remove one dependency on "Data Recvd" #580

Meeting records

Present: Will, JIB, Randell, Lucas,

The meeting was adjourned due to insufficient quorum. There were no minutes recorded. Agenda items will be moved to next meeting.

WebTransport Bi-weekly Virtual Meeting #75 late - February 27, 2024

WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m5904c63dd34fc592c2376e313cf19520 LATE Meeting number (access code): 126 406 0454

Agenda

General - Feedback on pooling from IETF interim. Bernard - Discuss Eric's proposal and its effect on the API.

  • Issues
    • WPT tests are needed for serverCertificateHash feature #589
    • Should the constructor take http3Only or something more transport agnostic? #561
    • Quality of a bandwidth estimate #559
    • Expose State internal slot #539
    • WebTransport API and ManagedMediaSource API #522
    • Relative send priority between datagrams and streams #451
    • expose a TLS Keying Material Exporter / unique value for the TLS session #411
    • CSP policies for WebTransport? #59
  • PRs
    • Remove one dependency on "Data Recvd" #580
    • Default to allow the server to create >= 100 uni and >=100 bidi streams. #593
    • Add example for server certificate hashes #592

Meeting records

Present: Will, JIB, Bernard, Randell, Victor, Eric, Nihdi, Lucas,

  • Minutes
    • Meeting was recorded and is available [1] along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
    • General
      • Feedback on pooling from IETF interim. Bernard - Discuss Eric's proposal and its effect on the API. - Eric - revolves around flow control, how do I determine if i can send again, gut feeling is that it’s a no-op for W3C. Bernard - do people need to set some sort of initial limits? Eric - let’s wait, this seems fully up to the browser. Let’s see how it lands in the underlying spec, then make a call on API shape. @Chairs - let’s have an issue to do the audit. Bernard - do we need this for WT 1.0, or can it wait until after CR. Eric - hesitant to say we can do it later.
      • Randell – H2 support is going to be a blocker to WT implementers. Bernard - split in to 2 groups - those with existing apps already have an alternate solution, while greenfield solutions care more about pervasive support. Randell - I’m pushing to get it H2 in, Eric, we plan to add it. Victor, I have written it into Quiche library. Nidhi - that would be my team in Chrome, comes down to priorities.
    • Issues
      • Expose State internal slot #539 - JIB , I have changed my mind on this. Now think we should expose state. We went with promises. Randell - what is need for polyfill? JIB - useful for debugging. It would be trivial to expose state that people could read. People might then want event model, but we could push back on that. Randell - do we want a more promise-based API surface? If so, then we should not do this. Bernard - how would this help for debugging without events? Randell - I don’t see a driving requirement for this , only an echo of an older API style. JIB - polyfill seems to have side-effects (trigger unhandled rejections). Eric - this would just be a convenience feature. Is it the neighborly thing to do? Seems easy to do. JIB - low cost and seems convenient. There is not ambiguity here. Nidhi - streams spec is promised based, no states there. Eric - matching Streams spec would make sense. Suggestion to reach to Streams spec folks on ways to observe promises without interfering with the browsers unhandled rejection handling.
    • PRs
      • Remove one dependency on "Data Recvd" #580 - still in Victor todo list.
      • Default to allow the server to create >= 100 uni and >=100 bidi streams. #593 - reviewed language. Eric - this doesn’t not encourage people to save resources if they require less than 100 streams. Lucas - you only need 3 streams for H3. No problems with 100. Victor - I’d like to bump to 128. Randell - in general I’m in favor of larger defaults. Eric - can we base the number on a real-world value? Victor - it’s not about the server. IETF spec has no requirements on the server. Randell - no requirement to buffer these streams. JIB - clarify - this is a min not a max. Eric - we have to be willing to let you use the streams we said you could use and it can’t be a trivial amount of memory. Bernard - say I’m sending a lot of stuff and hitting flow control limits on client, and server asks for more streams. Will - is this concurrent or cumulative? Should tighten language. Lucas - RFC9000 uses “initial”. JIB adjusted language. Victor - my intent here is to give more promises than UA would normally give. Bernard - other tests needed? Lucas - in Cloudflare Quiche, we give a new credit every time we close a stream. JIB - should we provide a default value for AnticiaptedConcurrentIncomingBidirecvtionalStreams? No objection to merging. @Chairs - open new issue on default value for ACIBS. Merged.
      • Add example for server certificate hashes #592 - reviewed. Eric - it does feel dangerous, but can’t articulate why it’s less secure. Randell, yes its processed on server, but that’s not unusual. Merged.

WebTransport Bi-weekly Virtual Meeting #74 early - February 13, 2024


WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m6a263598d572ab9d28d0e96df485d23d EARLY Meeting number (access code): 126 078 4125


Agenda

  • Issues
    • Should the constructor take http3Only or something more transport agnostic? #561
    • Quality of a bandwidth estimate #559
    • Expose State internal slot Discuss at next meeting #539
    • WebTransport API and ManagedMediaSource API #522
    • Relative send priority between datagrams and streams #451
    • Client initiated drain Discuss at next meeting #436
    • expose a TLS Keying Material Exporter / unique value for the TLS session #411
    • CSP policies for WebTransport? #59
  • PRs
    • Add more conditions for garbage collection #587
    • Remove one dependency on "Data Recvd" IETF dependency #580
    • Add anticipatedConcurrentIncoming[Bi/Uni]directionalStreams attributes & constructor arg #574

Meeting records

Present: Will, JIB, Victor, Bernard, Randell, Lucas, Peter.

  • Minutes
    • Meeting was recorded and is available [2] along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
  • Issues
    • Working with servers behind a NAT or on a local network (aka "p2p") #590 - Peter, people ask me how to run a server behind NAT. Interest in IETF for p2p QUIC. Should it be a separate spec? Victor - how much of those use cases are already addressed by server certificate hashes API. What are specific things people want to do here? Peter - server certs are half the solution. Other half is the network. With WebRTC, can do mDNS discovery. JIB, can you use WebRTC for discovery and then WebTransport . Bootstrap WT connection. JIB - can you polyfill mDSN in JS? If we allowed using WebTransport with ICE transport. Victor - decoupling this would be interesting. JIB - mDSN is there to not leak local IP addresses. Randell - cleaner way to do it would be to separate out ICETransport. Chairs can tag for future version.
    • Should the constructor take http3Only or something more transport agnostic? - #561 - bernard, suggested to close , speculative. EK to respond.
    • WebTransport API and Managed - MediaSource API #522 - basic question, is performance on mobile devices. Will - will this work with WebTransport as well as Fetch? Bernard - MSE has not been transport specific to date. @Will to write back to JY. Not much that Webtransport can do here. With MoQ, data is pushed to you, so you have less control. Bernard - Marco is looking at implementing this on Chrome.
    • Client initiated drain #436 - JIB - if you call multiple times, does it send. If it exists in IETF, we should expose it. Draining is sent over a control stream, so it will be reliably received. Ready-for-PR. @Will to try. Victor to review.
    • expose a TLS Keying Material Exporter / unique value for the TLS session #411 - closed due to lack of developer interest, but this has now been expressed. Bernard - use case is general enough for TLS exporters. Peter- trying to bootstrap handshake into another protocol. General agreement this will be useful and people asking for it. Victor - need to reopen IETF issue and add text in IETF spec. Labelelled IETF dependency.
    • CSP policies for WebTransport? #59 - JIB - how should CSP interact with server certificate hashes.? Victor - currently CSP will disallow you to connect to any host that is not example.com, for example. What if it overrides the certificate? JIB, seems exploitable. Victor - very elaborate setup. JIB - anyone have a solution? Victor - one proposal was to solve this at CSP level, but that’s not our spec, not sure how extensible CSP is. JIB - for WebRTC we turned off CSP entirely. Victor - a flag that says all my connect sources require real certificates would be a possibility, similar to WebRTC. Group - let’s explore whether this option is feasible. Chairs will look and come back.
  • PRs
    • Add more conditions for garbage collection #587 - reviewed updates. JIB - is this modification to getStats relevant to PR? No objections to merging without that part. Editors-can-integrate.
    • Remove one dependency on "Data Recvd" IETF dependency #580 - Victor, did not open issue.
    • Add anticipatedConcurrentIncoming[Bi/Uni]directionalStreams attributes & constructor arg #574 - reviewed. Bikeshed name but could not come up with better ones. Editors can integrate.

WebTransport Bi-weekly Virtual Meeting #73 late - January 30, 2024

WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m5904c63dd34fc592c2376e313cf19520 LATE Meeting number (access code): 126 406 0454

Agenda

  • General - our charter has been extended to May 31st 2024. This allows us to publish again on /TR/. We will recharter before this deadline.
  • Issues
    • serverCertificateHashes really only allow if not pooled? #579
    • Should the constructor take http3Only or something more transport agnostic? #561
    • Quality of a bandwidth estimate #559
    • Relative send priority between datagrams and streams #451
    • Client initiated drain #436
    • CSP policies for WebTransport? #59
  • PRs
    • Add reference for "first-strong" #588
    • Add more conditions for garbage collection #587
    • Add note about unavailability of stats #586
    • Add expiredIncoming #585
    • Add examples for reading with BYOB readers #584
    • Remove dependency on Data Recvd signals in cleanup #582
    • Remove one dependency on "Data Recvd" #580
    • Add anticipatedConcurrentIncoming[Bi/Uni]directionalStreams attributes & constructor arg #574
    • Add writer.atomicWrite() method. #551

Meeting records

Present: Will, JIB, Nidhi, Randell, David, Eric, Martin, Bernard , Victor

  • Minutes
    • Meeting was recorded and is available here along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
  • Notes:
    • General - our charter has been extended to May 31st 2024. This allows us to publish again on /TR/. We will recharter before this deadline.
    • Issues
      • serverCertificateHashes really only allow if not pooled? #579 - bernard, I don’t understand, why would you have that as a requirement? Victor - if your request does not . David - all google servers advertise datagram support. . Call agreement that we do want to support pooling. Do we need to change fetch? No strong interest in changing language at this time.
    • PRs
      • Add reference for "first-strong" #588 - no objections. Merged.
      • Add more conditions for garbage collection #587 - needs review. Randell - may be guaranteed elsewhere.
      • Add note about unavailability of stats #586 - unavailable entries will be absent from the dictionary. Bernard - we want to assume implementation. JIB - we may want to simplify to say that any unavailable stats will be absent. Bernard - that looks ok. Merged after edit.
      • Add expiredIncoming #585 - had expiredOutgoing, just making symmetric. No objections. Merged.
      • Add examples for reading with BYOB readers #584 - took examples from streams spec for BYOB readers and applied to datagrams. No objections. Has conflicts following atomic write. Nidhi to rebase and fix. Editors and integrate.
      • Remove dependency on Data Recvd signals in cleanup #582 - just removes it from cleanup. No objections, merged.
      • Remove one dependency on "Data Recvd" #580 - Victor has objection in issue. You will be unable to reset streams that the sender has sent a FIN on, which is why that step was added in the first place. Eric - does this make it take longer when you try to clean up streams? This seems like we have a desire to remove a signal that we depend on for other actions. Martin - may be case where we do need this line in place, but then condition on type of transport underneath. If you want to abandon data you have already sent, this is how you would do it. JIB - sending unreliable data over H2 is not going to work. Eric - can we nail down how stream spec handles this? JIB - why is stream spec the problem. Martin - stream will accept data and resolve all promises, but nothing has actually been sent. Victor - we should rewrite this to be something like ‘data committed’. Martin - we would need something in IETF if we want to keep the issue. Victor got volunteered to go in overview and definition of the streams.
      • Add anticipatedConcurrentIncoming[Bi/Uni]directionalStreams attributes & constructor arg #574 - for the win, longest attribute name. Martin - this is fine, all it is saying is to take this into consideration. However, what is missing is the H2 reference. Eric - lower layers will have to do some sort of math. Maybe have spec be less prescriptive about MAX_STREAM frames. JIB asked Eric and martin to add comments to PR. Eric - name says what it does. Leave open for comments and review at next call.
      • Add writer.atomicWrite() method. #551 - no longer overwrite the write method, all changes in the sink. Atomic chunk will not be sent unless it can fit in the flow control window. Bernard - does this add latency? Martin - no latency involved, fails immediately if you can't write. But if global window is taken up by , fallback is to not generate atomic state. Bernard, we should provide some advice as to what applications should do. Martin - doesn't hide latency in flow control blocks. Gives you an immediate callback. Could re-encode at a lower resolution and send again. JIB - this is much more deterministic when it fails. Bernard - this may be useful for sending i-frames. JIB - recommendation is to always await your atomicwrites. No objections. Merged.

WebTransport Bi-weekly Virtual Meeting #72 early - January 16, 2024


WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m6a263598d572ab9d28d0e96df485d23d EARLY Meeting number (access code): 126 078 4125

Agenda

  • Issues:
    • serverCertificateHashes really only allow if not pooled? #579
    • Should the constructor take http3Only or something more transport agnostic? #561
    • Quality of a bandwidth estimate #559
    • Provide flow control minimums from the browser side #541
    • API handling of redirects#499Does sendRate drop if I stop sending? #476
    • Relative send priority between datagrams and streams #451
    • Client initiated drain #436
    • Expose a TLS Keying Material Exporter / unique value for the TLS session #411
    • CSP policies for WebTransport? #59
  • PRs
    • Add concurrentIncoming[Bi/Uni]directionalStreams constructor arg. #574
    • Add writer.atomicWrite() method. #551

Meeting records

Present: Will, JIB, Lucas, Randell, Harald, Peter

  • Minutes
    • Meeting was recorded and is available here along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
  • Notes:
    • General - Randell, reporting that Mozilla are trying to expand web platform tests for serverCertifcate hashes, trying to get working in WPT infrastructure.
    • Issues:
      • serverCertificateHashes really only allow if not pooled? #579 - FF does not currently support pooling, so irrelevant to FF. Do we want to allow pooling of custom serverCertificateHashes? Randell - orthogonal in theory. We could simply say no pooling of serverCertificateHashes. Pooling is a perf optimization, hashes are a security feature. If you reuse a connection, your congestion control window is open so you avoid slow start. JIB - is there a benefit to opening a second session between client and server? Will - what if there is a separate app making the same connection? Randell - might be low priority given the work involved. Can prohibit now and punt to future.
      • Should the constructor take http3Only or something more transport agnostic? #561 - skipped since Eric absent
      • Quality of a bandwidth estimate #559 - no advance in discussion.
      • Provide flow control minimums from the browser side #541 - Randell - 100 seems like a high minimum. Harald - set to lowest observed today (100). Ready-for-PR.
      • API handling of redirects#499 - does anyone want to expose anything about redirect? No interest in exposing it and no clear use case. We should clarify in our spec that we don’t expose this with a note as to why, echoing Adam’s text. Ready-for-PR.
      • Does sendRate drop if I stop sending? #476 - Peter - may be a max bitrate we want the browser to probe up to. Depends on CC algo. Harald, this is a number above which the browser might drop your packet. JIB - happy to close this issue. Point back at #559.
      • Relative send priority between datagrams and streams #451 - sendGroups are orthogonal to sendGroups. Randell - we should be explicit about it either way.
    • PRs
      • Add concurrentIncoming[Bi/Uni]directionalStreams constructor arg. #574 - setter not yet ready. Defer to next meeting.
      • Add writer.atomicWrite() method. #551 - got feedback from Adam which was addressed by JIB. Removed need to modify write method. Also errors stream with AbortError at point where reordering would occur. Martin also good with it. No concerns expressed. Re-requested review from Adam and Martin.

WebTransport Bi-weekly Virtual Meeting #71 early - December 19th, 2023


WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m6a263598d572ab9d28d0e96df485d23d EARLY Meeting number (access code): 126 078 4125


Agenda

  • General - reminder that the scheduled meeting for Jan 2nd is cancelled due to holiday proximity. Next call will be on Jan 16th
  • Issues
    • Should the constructor take http3Only or something more transport agnostic? #561
    • Quality of a bandwidth estimate #559
    • Provide flow control minimums from the browser side #541
    • Reconsider whether we need sub-protocol negotiation #536
    • API handling of redirects #499
    • Relative send priority between datagrams and streams #451
    • Client initiated drain #436
    • CSP policies for WebTransport? #59
  • PRs
    • Add concurrentIncoming[Bi/Uni]directionalStreams constructor arg. #574
    • Add writer.atomicWrite() method. #551

Meeting records

Present: Harald, JIB, Bernard, Will, Randell

  • Minutes
    • Meeting was recorded and is available here along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
    • Notes:
      • General - reminder that the scheduled meeting for Jan 2nd is canceled due to holiday proximity. Next call will be on Jan 16th.
      • Issues
        • Should the constructor take http3Only or something more transport agnostic? #561 - Randell, seems an editorial issue, generic is nice but not super-important. Harald - Not visible to application developers.
        • Quality of a bandwidth estimate #559 - Harald - bw limiting occurs in n2 variants - one is wire just isn’t any faster, or 2, limited by congestion. WOuld prefer a flag for network limited, indicating that UA delayed some data. Packet loss from non-congestion control reasons. Sometimes exposing these signals causes apps to reinvent congestion control. @randell - to speak to Lars, since he is a congestion control researcher. Most congestion controller looking at smoothing over a few RTTs. Can we get use-case? HLS ABR decision, needs for 5s, WebRTC encoder needs to know next frame. Bernard - I want to know the congestion window. Might want a key frame size that avoids multiple round trips. JIB - could also give two values. Will- app could do its own smoothing for. @Will to document 3 use-cases in issue.
        • Provide flow control minimums from the browser side #541 - should spec say something about the default value? In chrome, it is 100. In Firefox, Randell to check. @Randell to check the code and also decide if we need a fixed limit. Will - why would it not work if it was 1 or 2? Wouldn’t QUIC negotiate more?
        • Reconsider whether we need sub-protocol negotiation #536 - looked at proposed API surface. Do we need strong length limits or will developers use these as backdoor headers? Also need a unique error. Harald - parsers must support tokens with at least 512 chars. 16384 bytes sequences. Maybe look at WebSocket for mitigations. Marked ready-for-PR.
        • API handling of redirects #499 - question is whether we tell the client it got redirected, or just close with an error. Bernard - we should not expose the redirected URL in the API. Will - useful for debugging. JIB - do we need a different error for an algorithmic response, Do we expose a) that we got a 3xx error? And b) we got the 3xx error and a redirect URL? Harald - no point in exposing a URL for redirecting. Bernard - just expose the code. Will- do we expose all codes or just for redirects? We should bring this up for Webtransport interim as a W3C question.
      • PRs
        • Add concurrentIncoming[Bi/Uni]directionalStreams constructor arg. #574 - no progress.
        • Add writer.atomicWrite() method. #551 - state is waiting for answer from Adam.

WebTransport Bi-weekly Virtual Meeting #70 late - December 5th, 2023

WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m5904c63dd34fc592c2376e313cf19520 LATE Meeting number (access code): 126 406 0454

Agenda

  • General: Options for storing meeting video records and transcripts. We can upload to W3C Youtube account and have videos as private, or public-with-link. Transcripts do contain attribution. Can also delete videos completely. Prior meeting decision was to store on Youtube privately. Does this group agree?
  • Holiday timing - Next call as scheduled on Dec 19th. The Jan 2nd call is cancelled, first call of 2023 will be Jan 16th.
  • Issues
    • Clarify what sending "completed" means e.g. wrt. flow control #571
    • Allow more aggressive garbage collection #560
    • Quality of a bandwidth estimate #559
    • Reconsider whether we need sub-protocol negotiation #536
    • WebTransport http2 idea's suggestions #518
    • Allow datagram send order relative to streams to be application defined #451
    • Client initiated drain#436
    • CSP policies for WebTransport?#59
  • PRs
    • Add concurrentIncoming[Bi/Uni]directionalStreams constructor arg. #574
    • Add feature-detection of HTTP/2 fallback. #568
    • Reject in-flight write promise on network error. #566
    • Update spec with transport agnostic language #562
    • Add writer.atomicWrite() method. #551

Meeting records

Present: Will, JIB, Martin, Eric, Nidhi, Victor, Bernard, Randell.

  • Minutes
    • Meeting was recorded and is available here along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
    • Notes:
      • General: Options for storing meeting video records and transcripts. We can upload to W3C Youtube account and have videos as private, or public-with-link. Transcripts do contain attribution. Can also delete videos completely. Prior meeting decision was to store on Youtube privately. Does this group agree? Yes.
      • Dates - The regularly schduled call for Jan 2, 2024 will be cancelled due to holidays. All other calls proceed as planned.
      • Issues
        • Clarify what sending "completed" means e.g. wrt. flow control #571 - Bernard - this is a duplicate of #426. Martin - I support option 1 “been buffered for sending”, as does Randell. JIB - await.ready is different from write promise resolving. This issue came from Randell writing unit tests for sendOrder. Meeting agreed - answer is no. Issue closed.
        • Allow more aggressive garbage collection #560 - JIB - does this make sense? No objections heard. Marked as Ready-for-PR.
        • Quality of a bandwidth estimate #559 - Randell, knowing what you can send at this moment is handy. Martin - idea that you can ask the browser what the send rate is, is a bit flawed. I’ve found applicationLimited and slowStart to be unreliable. I would avoid anything specific to congestion controllers, rather indicate whether it is reliable or not. Bernard - what would an app do with this? Randell - I would have a boolean for “stability”. Eric - applicaitonLimited means you might have more throughput if you send more. This metric is useful at startup, better than being blind. Can speed up convergence to true value. Can tell app should I try to push harder. Bernard - this depends on congestion algorithm. Randell - we need a better feedback to real-world applications. Bernard - my use case is sending simulcast - can I add a layer? Victor - our QUIC stack has ability to probe. Randell - applications could probe on parallel streams, or datagrams with zero timeout. Bernard - can you control in WebTransport? Victor - currently nothing in WT.
      • PRs
        • Add concurrentIncoming[Bi/Uni]directionalStreams constructor arg. #574 - for discussion. Set limit to 65K using unsigned short. No readable, set only at construction. Will- isn’t there a need to change at a later date? JIB - no, keep it simpler. Martin - setter not so complex. IN conferencing for example, you could change your threshold. Only change is making it an attribute. JIB - will add setter? Will do to this PR>
        • Update reference from RFC6125 to RFC9525. #576 - fixed by #562. Eric - let’s not say Http2. Rather say “reliableTransport”. Martin - let’s say “is exclusively reliable/. Committed change and Merged.
        • Add feature-detection of HTTP/2 fallback. #568 - was closed and replaced by #575
        • Reject in-flight write promise on network error. #566 - Eric - what is this actually doing? In clean-up procedure, if stream has pending operation, we have to reject stream. Why do we duplicate streams inflightwriterequest? JIB -we do our own bookkeeping. Martin - to keep layering in streams, we must keep a copy of pending operations. No objections - merged.
        • Update spec with transport agnostic language #562 - most language has been addressed. JIB - LGTM. Approved and merged.
        • Add writer.atomicWrite() method. #551 - JIB added note concerning interaction with streams API, new API needs to deal with simultaneous use of write.write, not pipeTo or PipeThrough. Martin - if I release a lock on a stream, does it release immediately without waiting for write to complete? JIB - yes. Have note that applications are encouraged to always await atomic writes. Nidhi will look this week.

WebTransport Bi-weekly Virtual Meeting #69 early - November 21st, 2023


WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m6a263598d572ab9d28d0e96df485d23d EARLY Meeting number (access code): 126 078 4125


Agenda

  • Options for storing meeting video records and transcripts. We can upload to W3C Youtube account and have videos as private, or public-with-link. Transcripts do contain attribution. Can also delete videos completely.
  • Issues
    • Should all fields in WebTransportConnectionStats be nullable? #567
    • Allow more aggressive garbage collection #560
    • Quality of a bandwidth estimate #559
    • Improve Server→Client Stream Performance by Allowing Customizable Concurrency Limits in WebTransport #544
    • WebTransport http2 idea's suggestions #518
    • Client initiated drain #436
  • PRs
    • Add feature-detection of HTTP/2 fallback. #568
    • Reject in-flight write promise on network error. #566
    • Fix missing |promise| reference in abortSignal algorithm. #564
    • Update spec with transport agnostic language #562
    • Reject getStats() promise when the connection is closed/failed. #558
    • Add writer.atomicWrite() method. #55

Meeting records

Present: Will, Victor, JIB, Harald, Randell, Peter.

  • Minutes
    • Meeting was recorded and is available [Link here] along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
  • General
    • Options for storing meeting video records and transcripts. We can upload to W3C Youtube account and have videos as private, or public-with-link. Transcripts do contain attribution. Can also delete videos completely. JIB - publish transcripts, keep videos but private. Harald - experience in WebRTC, no-one minds on Youtube, and transcripts are frequently erroneous. Peter- keep recording, no pref on private or public. Decision - review at next meeting then store on Youtube.
  • Issues
    • Should all fields in WebTransportConnectionStats be nullable? #567 - what happens to stats in h2 case? Not all stats will be consistently available. Could leave undefined. JIB - dict allows members to be absent. Harald - zero is frequently a valid value. If required, we should use the required keyword. In favor, if you can’t compute, don’t populate the entry. Victor - absence, but we should add informative text that availability is subject to platforms. Assigned to Victor.
    • Allow more aggressive garbage collection #560 - UA would be able to reclaim resources. Randell - you should check with Kagami for review. Objections to specifying this? Harald - what’s rule about garbage collecting streams? May not need this. JIB - no premise for promises keeping things alive. Randell - would only allow GC, not require it. Ask @Adam for review. Victor - what if you have a pending promise to create a stream? JIB - our understanding is that promises don’t keep things alive.
  • PRs
    • Add feature-detection of HTTP/2 fallback. #568 - no way to feature-detect if browsers support H2. We don’t currently have a way to detect that. Design principal says new features should be detectable. We don;t currently set wt.reliability on failure. So could overload to report “reliable-only” if H2 is supported. Victor - that sounds a bit counterintuitive. What if we return an array which on failure tells you what protocols/features were attempted? Will come back to this. Peter - likes Victor’s array idea. Will - would array be a fingerprinting surface? Victor - could . JIB - another idea WebTransport.supportsReliableOnly
    • Reject in-flight write promise on network error. #566 - need comment from Adam or Nidhi.
    • Fix missing |promise| reference in abortSignal algorithm. #564 - randell, sounds sensible. Reviewed and merged.
    • Reject getStats() promise when the connection is closed/failed. #558 - rewrote to agreement,if connecting, wait, if failed, reject, if closed return most recent available. Approved and merged.
    • Add writer.atomicWrite() method. #55 - Victor would prefer Nidhi or Adam to review as they have better understanding of stream spec.
    • Make estimatedSendRate be null instead of undefined #573 - simple, null instead of undefined for estimateSendRate. JIN - do we need ECMAScript reference? Group agreed to remove. No objections to merging. Merged.
    • Add a waitUntilAvailable option to stream creation #572 - addresses issues with flow control and streams. JIB - reviewed and approved. LGTM. Merged.
    • Move normative prose in send algorithms out of notes. #570 - accepted Victor suggestion. Approved and merged.

WebTransport Bi-weekly Virtual Meeting #68 early - October 24th, 2023


WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m6a263598d572ab9d28d0e96df485d23d EARLY Meeting number (access code): 126 078 4125


Agenda

  • Issues
    • estimatedSendRate absent vs null #554
    • Add expiredIncoming to stats #553
    • Improve Server→Client Stream Performance by Allowing Customizable Concurrency Limits in WebTransport #544
    • WebTransport http2 idea's suggestions #518
    • MAX_STREAM limit (ingest) (still need an event when stream ids become available again) #446
    • Client initiated drain #436
  • PRs
    • Remove timestamp from all stats objects #552
    • Add writer.atomicWrite() method. #551
    • Reject getStats() promise when the connection is closed/failed. #558
    • Fix wrong internal slot in a note about the datagrams queue. #556
    • Make incomingMaxAge and outgoingMaxAge nullable again. #555

Meeting records

Present:

  • Minutes
    • Meeting was recorded and is available here along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
  • Issues
    • estimatedSendRate absent vs null #554 - should change to must be null. JIB, since dict, could also drop member. Victor - null over undefined makes feature detection easier. Ready-for-PR. Assigned Victor.
    • Add expiredIncoming to stats #553 - no disagreement. Ready-for-PR.
    • Improve Server→Client Stream Performance by Allowing Customizable Concurrency Limits in WebTransport #544 - changed subject to clarify server2client. Will be concurrent limit, not absolute. Bernard - in case of pooling - is it MAX concurrent streams for my session? JIB - is max-limit frame for all sessions? UA could manage this. Proposed API is per session. Victor - the limit of client initiated bi-di is determined by the server. This would be incoming uni-di and incoming bi-di. Should be separate controls. JIB - can we have one API that sets both? Lucas - in H3, QUIC keeps them independent. Should do same here. maxConcurrentIncoming UnidrectionalStreams and maxConcurrentIncomingBidrectionalStreams, Victor - you can ask for these, but you are not guaranteed to get. This is a hint. Also, what about case of pooled connections, perhaps for IETF. Should we also add getter/setter? Victor - let’s start with constructor only. Lucas - getter is not bad knowing what you have. Victor - should spec cover minimums and defaults? Agreement to proceed with this. Ready-for-PR.
    • WebTransport http2 idea's suggestions #518 - call consensus that we should not expose the underlying protocol. No H2 implementation yet. No current advocates for doing this. Left open with comment.
    • MAX_STREAM limit (ingest) (still need an event when stream ids become available again) #446 - Victor, don’t like event approach, concerned with behavior where you open streams before you are connected. TPAC proposal was have an option to reject or block, with default to reject. Better than having app silently wait with performance drawbacks. Ran out of time. Ready-for-PR. Assign to Victor.
  • PRs
    • Remove timestamp from all stats objects #552 - no objections. Merged.
    • Add writer.atomicWrite() method. #551 - Victor not had time to review. Skip for next call.
    • Reject getStats() promise when the connection is closed/failed. #558 - Bernard, we return stats that were there when connection closed, instead of rejecting. Victor - does require you to record stats before tearing down connection. Randell - should reject on failed, because no stats. But on close, give final stats. Victor - how should behave when state is connecting? Would prefer to not return zeros. Should hold until connected. JIB - prefer to succeed before connection. Bernard/JIB prefer pre-connection data. Lucas - do bytes sent include initial packets? JIB - can bytes sent go up before the connection? Victor - if you return data before completing webtransport handshake, you are leaking data about shared traffic. Should block until connection is ready. Lucas supports. Victor will update PR.
    • Fix wrong internal slot in a note about the datagrams queue. #556 - editorial. Merged.
    • Make incomingMaxAge and outgoingMaxAge nullable again. #555 - reviewed. No objections. Merged.

WebTransport Bi-weekly Virtual Meeting #67 late - October 10th, 2023

WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m5904c63dd34fc592c2376e313cf19520 LATE Meeting number (access code): 126 406 0454

Agenda

  • General - next TPAC now set for 23-27 September 2024 in Anaheim, USA. Save the date.
  • Issues
    • Improve Stream Performance by Allowing Customizable Concurrency Limits in WebTransport #544
    • Busy requestAnimationFrame Causes WebTransport Send Queue Starvation #543
    • Reconsider whether we need sub-protocol negotiation #536
    • WebTransport http2 idea's suggestions #518
  • PRs
    • Add writer.atomicWrite() method. #551
    • Set optimizeForLatency in decoder configuration #549
    • Add Senders, and make sendOrder no longer nullable. #548

Meeting records

Present: Will, Eric, Nidhi, JIB, Randell, Martin, Victor, David,

  • Minutes
    • Meeting was recorded and is available here along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
    • Notes:
      • General - next TPAC now set for 23-27 September 2024 in Anaheim, USA. Save the date.
    • Issues
      • Improve Stream Performance by Allowing Customizable Concurrency Limits in WebTransport #544 - . martin #446 is more interesting. Can this be adaptive on the part of the browser - keep up with server creation rate. Randell - what argument against adaptation? Martin - multiple round trips so can;t adapt fast enough. SImplest way for application, set value to X. JIB - like adaptive until we have more. Martin - adaptive comes with a perf bug. Will - could have adaptive and the API active. Will - is this absolute or concurrent limit? Victor - MAX_LIMIT is absolute in protocol, but not in the browser.
      • Timestamp in the Stats object #550 - measures how loaded your queue is. Worried about timing attacks. Group consensus. OK to remove. Ready-for-PR and assign to Victor.
    • PRs
      • Add writer.atomicWrite() method. #551 - Martin - only one inconsequential comment so far. Stream writing logic concerns me and interleaving with two function calls - write() && atomicWrite(). Martin - ok with flipping to an atomicWrite behavior if interleaving. JIB - should add note that best practice is to await an atomicWrite. Randel - LGTM. JIB - For error name, chose transactionInactiveError. Group thinks abort is more accurate. Martin - it doesn’t define what blocking means. There might be a race condition. If you enqueue regular bytes, test will set atomic to true if someone else queues an atomic write behind it. 1 byte left on stream and then send 1 byte. Does that cause atomic write to be aborted? JIB, yes.Victor - what if non-atomic write before my atomic? JIB - if there is a blockage of the non-atomic, then your atomicWrite is also blocked. Victor - alt approach is to take atomicWrite and check at de-queueing time. Martin - better to queue and decide on credit at send time. Remove “Whenever the sending of bytes becomes blocked..” because we want to allow queueing atomic write behind non-atomic ones. Also if you cannot send all the bytes of an atomic request within the current flow control window, queue a task to abort all of them. JIB - will add and expose to group for another review.
      • Set optimizeForLatency in decoder configuration #549 - two liner fix. Merged.
      • Add Senders, and make sendOrder no longer nullable. #548 - Victor, no time to review. Unsure about name. Would prefer “sendGroup” and “sendOrder”. Would merge with that change. Martin - did you need to bundle in changing default sendOrder to 0? JIB - yes. Victor - do we have limits? Not yet. We can reject on constructor if the UA does not want to support additional groups. Randell - forces error handling logic. What is reason for arbitrary limit? It’s all local. Would strongly prefer to not have a group limit. Editors-can-integrate after name change.

WebTransport Bi-weekly Virtual Meeting #66 early - September 26th, 2023


WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m6a263598d572ab9d28d0e96df485d23d EARLY Meeting number (access code): 126 078 4125

Agenda

  • Issues
    • Improve Stream Performance by Allowing Customizable Concurrency Limits in WebTransport #544
    • Busy requestAnimationFrame Causes WebTransport Send Queue Starvation #543
    • Reconsider whether we need sub-protocol negotiation #536
    • WebTransport http2 idea's suggestions #518
  • PRs
    • Reject create(Uni|Bi)directionalStream() on stream ID exhaustion. #528
    • Add getAtomicWriter() API. #502

Meeting records

Present: JIB, Will, Bernard, Harald, Peter, Randel, Victor.

  • Minutes
    • Meeting was recorded and is available here along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
  • Issues
    • Improve Stream Performance by Allowing Customizable Concurrency Limits in WebTransport #544 - suggestion to provide hint to browser on number of streams to be created. Server is sending 10,000 streams to client. More details are needed. Next step is get more info on what is going and verifying that this a maxStreams issue. Bernard to add to issue - we need a sample of the reader.
    • Busy requestAnimationFrame Causes WebTransport Send Queue Starvation #543 - Webtransport slows down when RequestAnimationFrame is run. Browser is Firefox. Victor - in Chrome, they run on separate threads. Randell to take a look.
    • Reconsider whether we need sub-protocol negotiation #536- Victor - do we need it. No. Is it useful, yes. Request comes from Moq. Want to negotiate protocol version. Its the handler determination logic. IN Wt, you are required to read headers first. You offer list of strings and server picks one. This would require a new header from IETF.JIB - can we punt to IETF? Randell - what would API surface look like in UA? Victor - it would be a key in WT constructor. There is utility in knowing this data before you do any stream or DG handling. Can do in the app layer. Victor - app layer has complex structure. Will - a CDN that is standing up an open WT interface would like to know which protocol is coming down the pipe. Randell - this seems a reasonable argument to me.
  • PRs
    • Add getAtomicWriter() API. #502 - not ready.
    • Add Senders, and make sendOrder no longer nullable. #548 - as presented at TPAC. Allows WT.createSender(). By default, WebtransportSendstreams are ungrouped. Each sender is a separate space for evaluating sendorder numbers. Victor - people may find name ‘sender” confusing. SendOrder now defaults to 0. Victor - I need to read the PR. We’ll look at it at next meeting. Datagrams do not fit into this scheme. Could develop datagram.senders too.
    • Define [=underlying connection=] for connection-level stats. #547 - defines a concept of an underlying connection, stats renamed to WebTransportConnectionStats. Bernard LGTM. Changed status to editors-can-integrate.
    • Add stat bytesLost #546 - debate over . Victor - allows you to calculate % bytes loss/ . Victor - should be packetsAcknowledged and BytesAcknowledged. Randel - why do we need this? Don’t see a use for byte loss rate. Victor, had a congestion controller that worked in bytes rather than packets, so was perceived as a more useful metric. Could be because queues are sized in bytes and not packets. Randell, since bytes is payload, they are counted twice with retransmissions. Spec does indicate that retransmissions are included. Should have a follow-up on retransmissions for packets.
    • Remove stats numOutgoingStreamsCreated & numIncomingStreamsCreated #545 - simple removal of two stats. No objections, merged.
    • Reject create(Uni|Bi)directionalStream() on stream ID exhaustion.#528 - based on TPAC . Adds a new QuotaExceededError. . QuotaExceededError was the closest existing error to use. Needs an event, Victor is skeptical about that. Victor LGTM. No objections, merged.

WebTransport TPAC meeting - Seville 2023

September 12 17:00 CEST , 11:00 EST, 08:00 PST, 01:00 AEST and 00:00 JST.

WebEx Access

The link to the meeting, including the W3C managed Zoom link, is here: https://www.w3.org/events/meetings/d1c140fe-e006-4388-bd31-adeb1de4d431/

Agenda

  • [8min] State of WebTransport - changes since TPAC 2022
  • [10min] Demo by Bernard
  • [65min] - discussion of high priority issues
  • Clarify semantics of stats and their relationship to QUIC connection: #537
  • Priority groups #515
  • MAX_STREAM limit #446
  • Add writeAtomic() API. #426
  • [7 min] Plans for next year - Release Candidate timeline.

Meeting records

Present:JIB, Randell, Bernard, Florent, Peter, Piers, Varun, Victor, Martin, Nidhi, Eric, Chris, Youenn, Will.

  • Minutes
    • Meeting was recorded and is available along with a full transcript. For access please contact your chairs.
  • Notes:
    • State of WebTransport - changes since TPAC 2022 - see slides for details.
    • Demo by Bernard = observations, g2g latency is more than frame RTT. What is generating that? Looks like decode latency is greater than encode latency. Needs investigation. JIB - can you describe smoothness since we’re seeing over zoom. Yes, its smooth, Martin - is this browser agnostic? Can only test on Chrome due to webcodecs requirement. Randell - you may be able to enable webcodecs in FF. Have you tried other codecs? Bernard - yes, tried AVC, vp8, Av1 is highest latency. None of these have to do with web transport.
    • Clarify semantics of stats and their relationship to QUIC connection: #537 - do we need both bytes and packets.Randell - yes, datagrams are packet orientated. Bytes useful for streams. No problem leaking across both connections to same origin. Leaking to yourself, which obviates next 3 questions. Martin - same partition, not origin. Piers, QUIC packets or UDP packets? Martin - mostly will be 1:1 correlation, only in handshake will multiple QUIC packets be sent over one UDP packets. Piers - though on adding time info? JIB - there is a timestamp in dict. Defined as “when they are gathered”, may need more precision. Randell - please file an issue with a use case.
    • Priority groups #515 - Pitch by JIB for “Senders” to address fairness in sendOrder number spaces. Peter - sender could be integer, but object construct is interesting. Thinks interesting to add object for extensibility. Victor - I support. May want to limit number of senders. JIB - wt.datagrams would be an explicit sender. Will - why not extend to datagrams? JIB - right now there is one implicit sender for DG. Could extend in future. Piers - any mapping to H3 priority? Victor - H3 prioritization goes on top of this. Eric - how deep do you want to go? Should I include the sender index when I create stream? We are nesting abstractions?JIB - I assumed we would not add transport level support. Martin - bit concerned that magic is required for datagrams. If have to load balance between different senders, have to queue datagrams. Don’t like that. Eric - how much as to do with weighting? Is it safe and valuable to separate datagrams, versus how much to send? JIB - not hearing any object. Martin - is this the end? No more layering after this? JIB - stats and weights is OK. Victor - not sure we can ship stats or weights now.
    • MAX_STREAM limit #446 - Martin - that server is not one that I would deploy to inherent. Fiddle is a DOS attack. Server not responding correctly. Martin - what does browser do when server has limits? App should be able to request max . Will - max number or rate? Martin - max number that is concurrently active, don;t think rates help in any way. Bernard - for ingestion, numbers are fine. 10K streams is reasonable for game development. Martin - server operating here would set limits according to application. Therefore browser does not need to hit limit. JIB - can have promise reject, or blocked? Will - what about a CDN relay that is dealing with different apps? Martin - use application level signaling in that case. Eric - main thing we’re trying to protect memory resource. . JIb - preference for not having an API in javascript where app can ask for what they want. Martin - . Should reject. Therefore need and event when stream creation can proceed. Provides back pressure. Could there be race conditions with limit event and rejection? May be difficult for apps to handle correctly. IF rejected,, wait for limit expanded . Complex pancake analogy from Eric. Victor - only thing you would do with event, is to ask for another stream. So should be promise for a stream instead. JIB - would also be our first event. How about option on create stream to be willing to wait for stream creation. Victor - this is the correct answer. You know that you are waiting. If you add event, have to think really hard about when it fires. Martin - coming around to idea to stream creation parameter, that way people would opt in to perf problems.
    • Add writeAtomic() API. #426 - pitch for writer.writeAtomic(). Martin - LGTM.
    • Plans for next year - Release Candidate timeline. Request for all those with assigned PRs to please commit them.


WebTransport Bi-weekly Virtual Meeting #65 early - August 29th, 2023


WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m6a263598d572ab9d28d0e96df485d23d EARLY Meeting number (access code): 126 078 4125

Agenda

  • TPAC agenda, call for additional items + volunteers to cover highlighted issues.
  • Issues
    • Clarify the semantics of stats and their relationship to QUIC connection #537
    • Reconsider whether we need sub-protocol negotiation #536
    • Expose State internal slot #539
    • Support for CLOSE_FRAME #531
    • API handling of redirects #499
    • WebTransport http2 idea's suggestions #518
    • Retransmissions and send order #523
    • Priority groups #515
  • PRs
    • Add introduction to Section 3 #538
    • Remove potential race condition from encode and decode transform streams (WebCodecs Echo Sample) #530
    • Reject create(Uni|Bi)directionalStream() on stream ID exhaustion. #528
    • Add getAtomicWriter() API. #502

Meeting records

Present: Will, JiB, Harald, Victor, Bernard, Lucas.

  • Minutes
    • Meeting was recorded and is available here along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
    • TPAC agenda, call for additional items + volunteers to cover highlighted issues.
      • Issues
        • Clarify the semantics of stats and their relationship to QUIC connection #537 - JIB - if there are two WT sessions, should report independent numbers for each session. Victor more complicated than that - some stats defined in packets, which are not attributable to sessions when pooled. Loss detection and congestion control aren’t attributable to sessions. Victor - suggest remove stats not related to RTT. Incoming and outgoing prefixes are poorly worded. Bernard - some won’t be available when pooled but we could keep remainder. Will - preserving some stats on packet loss would be useful. Bernard - stats are useful for debugging problems. OK if on entire connection. Packets sent, lost, acknowledge. Triaged each stats in issue to reflect group opinion. Queue for TPAC. Also consider renaming.
        • Reconsider whether we need sub-protocol negotiation #536 - issue came from MoQ. Would make it easier to port raw quic apps to WT that don’t have an obvious URL. Lucas - RFC7639 for ALPN negotiation via header. JIB - websocket provides socket.protocol. Could be an optional constructor argument. Harald - ALPN is much like port numbers. Dangerous mechanism to expose if we don’t have to.
      • PRs
        • Add introduction to Section 3 #538 - reviews look good. Merged.
        • Add getAtomicWriter() API. #502 - no progress.
        • Use plotly graphing library instead of Google Graphs in samples #540 - for sample apps, merged.

WebTransport Bi-weekly Virtual Meeting #64 late - August 15th, 2023

WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m5904c63dd34fc592c2376e313cf19520 LATE Meeting number (access code): 126 406 0454

Agenda

  • TPAC - 12 September 2023, 17:00–18:30 CEST. Even if you are attending remotely, please register at https://www.w3.org/register/tpac2023. Fee goes up on Sept 1st.
  • Issues
    • Support for CLOSE_FRAME #531
    • Retransmissions and send order #523
    • WebTransport http2 idea's suggestions #518
    • Priority groups #515
    • API handling of redirects #499
  • PRs
    • Remove potential race condition from encode and decode transform streams (WebCodecs Echo Sample) #530
    • Reject create(Uni|Bi)directionalStream() on stream ID exhaustion. #528
    • getAtomicWriter() API. #502

Meeting records

Present: Will, JiB, Randell, Nidhi, Victor, Eric, Bernard.

  • Minutes
    • Meeting was recorded and is available [3] along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
  • Notes:
    • TPAC - 12 September 2023, 17:00–18:30 CEST. Even if you are attending remotely, please register at https://www.w3.org/register/tpac2023. Fee goes up on Sept 1st. Comment from Bernard that we need to develop agenda for TPAC as its coming up quickly.
    • Issues
      • Support for CLOSE_FRAME #531 - Victor - wait until someone asks for this. Use case is obscure. Consensus to wait. Leave open until CLOSE-FRAME exists on WebTransport.
      • Retransmissions and send order #523 - IETF feedback did not provide consensus. Chrome currently prioritizes retransmissions. So does Firefox. Eric - tempting to say we could add this later. Let’s wait. We can provide other info to help apps avoid priority inversions. You only care about this if you don’t need to receive in order. Complex implementation for a feature that would be hard to test. Can we make ready-for-pr with this note: retransmission ordering is at the discretion of user-agents, but are encouraged to happen at high priority.
      • WebTransport http2 idea's suggestions #518 - Victor, we discussed this during WebTransport development. Eric - we should add a note and encourage Martin to talk to IETF. Bernard - he can write a library. Eric - we intentionally want to avoid providing info specific to H2|H3. Bernard - he can try to use eBtransport
      • Priority groups #515 - can they be polyfilled, or are groups a simple and good starting point. Still interest in group. Leave as ready-for-PR.
      • API handling of redirects #499
    • PRs
      • Clarify Protocol concepts section (Section 3) #535 - reviewed and merged.
      • Reject create(Uni|Bi)directionalStream() on stream ID exhaustion. #528 -. Give app hint that it has reached max_stream_limit if create stream method rejected. Victor - we should block until next stream is available. Eric - may make sense to expose current stream limit to application. Randell - would prefer and error and a number. If you exceed limit and it’s never going to succeed. Options shown below. Decision to about it and come back at next meeting.
        • should create method fail or block
        • Should we expose the number?
        • Should we fire and event?
        • All of the above or some combo?
      • Reject promise if state is not "connected" in pull(Uni|Bi)directionalStream #534 - reviewed and merged.

WebTransport Bi-weekly Virtual Meeting #63 late - July 18th, 2023

WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m5904c63dd34fc592c2376e313cf19520 LATE Meeting number (access code): 126 406 0454

Agenda

  • Issues
    • cleanup does not specify what to do with the datagrams streams #524
    • Priority groups Discuss at next meeting #515
    • Retransmissions and send order #523
    • WebTransport http2 idea's suggestions #518
    • Should incomingUni/BidirectionalStreams be "owning"? #507
    • API handling of redirects #499
  • PRs
    • Add automated glass-glass latency calculation via RVFC #519
    • Add getAtomicWriter() API. #502
    • Cleanup Datagram Streams #526

Meeting records

Present:

  • Minutes
    • Meeting was recorded and available here along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
    • General - next meeting, let’s debate how to spend time at TPAC.
    • Issues
      • cleanup does not specify what to do with the datagrams streams #524 - fixed by PR #527
      • Priority groups Discuss at next meeting #515 - Will, should have weights from beginning. JIb - would be better to have groups first. Victor - we should be able to add weights easily in the future. JIB proposed API. Will - are datagrams their own implicit group? Victor - other change is that default sendOrder would be zero. Ready for PR. Review with other time slot.
      • Retransmissions and send order #523 - JIB, do we need to define? Will - we would want an API to allow the application to set the retransmission priority. Victor - would start with boolean toggle between sendOrder or retransmission? Might want to shelve for now until we discover this in practice. Bernard - set a timer on frame , not on individual transmissions. Bernard - catch up behavior of WARP does not make sense to me.
    • PRs
      • Add automated glass-glass latency calculation via RVFC #519 - reviewed and merged. Will will research API in Chrome to reduce decode latency.
      • Add getAtomicWriter() API. #502 - Victor did review. JIB updated API to improve mixing by overloading the writer. Victor - lot of interactions with stream API which were not clear to me, overall idea makes sense, should be possible to implement but timeline not clear. Is there anything we can provide on the receiving side to avoid flow control blocks? Google QUIC does not support atomic writes so far. JIB - something on the receiver side would not obviate the need for this API. Want to talk more with Eric Kinnear who may have an opinion on this. Victor - do we actually need a special writer? We could put an atomic object into the same writer? JIB - we want a boolean response. Victor - could you just reject the promise? We could invent a new AtomicBufferSource to reuse the write method. Seems strange for app to have to transform.
      • Cleanup Datagram Streams #526 - datagrams do have back pressure. Merged.
      • Update ranges of streamErrorCode #527 - JIB and Victor - LGTM, merged.

WebTransport Bi-weekly Virtual Meeting #62 late - June 20th, 2023

WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m5904c63dd34fc592c2376e313cf19520 LATE Meeting number (access code): 126 406 0454

Agenda

  • General. - TPAC meeting has moved to a final slot of Tuesday Sept 12th from 17:00 - 18:30. Follows WebRTC meeting.
  • Issues
    • WebTransport http2 idea's suggestions #518
    • Priority groups Discuss at next meeting #515
    • Should incomingUni/BidirectionalStreams be "owning"? #507
    • API handling of redirects #499
  • PRs
    • Add automated glass-glass latency calculation via RVFC #519
    • Add getAtomicWriter() API. #502

Meeting records

Present: Present: Will, Bernard, JIB, Eric, Victor, Nidhi,

  • Minutes
    • Meeting was recorded and is available here along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
    • Notes:
      • General. - TPAC meeting has moved to a final slot of Tuesday Sept 12th, 17:00 - 18:30. CET. Follows WebRTC meeting.
    • Issues
      • Priority groups Discuss at next meeting #515 - Randell , simultaneous media flows is the use case that makes sense for groups. Groups could be helpful for separating sendOrder number spaces. Victor - simple concept. Priorities represented by send Order or null. Changes to tuple of (group, SendOrder). Question about default - if you don;t specify group, it should get its own group instead of being thrown into a default group. Martin - only WT streams? Yes. JIB - proposed mediaflows last year, whereas grouping constructs are more general. Martin - would need to weighting of the groups. Mostly positive on groups. A priority group object may be better. Also a place to add weights (with limited value space), and limit number of groups. (<256). Defaults - every stream gets default group. Martin - if you don’t set group or sendOrder, then all your streams share bandwidth. Preserves existing behavior if stay away from groups and sendOrder. Will - are datagrams in their own group? Victor - put in default group. Martin - leave them out of grouping. Victor - you need some form of queue for datagrams, since subject to QUIC pacing. That queue takes precedence over stream. Datagram queue is time-bound and short.
    • PRs
      • UA SHOULD divide bandwidth fairly between all streams that aren’t starved #521 - Eric, if I don’t apply send order, seems to use byte-count more than stream count. Eric - because this stays within this session, you can only hurt ‘you’. Martin - Moz implementation currently has 3 buckets - unfair streams (needed by H3), then fair streams that don’t have send order, then streams with send-order. Victor - what kind of fairness do we mean? Every packet has bytes for each stream (not practical), sending streams one by one (avg over lifetime ), fairness over span of several roundtrips? JIB - let’s try not to define fairness. Victor - can you mention that the definition of fairness is implementation defined? Moz - round robins each packet between streams. Chrome - takes 8-64K slices from buffer. Editors-can-integrate. Victor - question - any text that clarifies how retransmissions are prioritized. Martin - QUIC spec deals with this. Victor - that will break some MoQ implementations. No way to say this stream is higher priority than retransmit of lower priority lost data.
      • Add automated glass-glass latency calculation via RVFC #519 - we need more investigation into latencies. Currently seeing 200ms in pipeline not accounted for by anything in webtransport. Similar delays to what Jordi Cezano is seeing with his MoQ demo. . Worth discussion at TPAC to find out exactly where pipeline delays are being incurred.
      • Add getAtomicWriter() API. #502 - going back to returning a boolean. Martin - you queue up promises and then if one fails then you fail them all? JIB - yes. Martin - the promise returned is not the promise that the underlying stream returned?JIB - correct. Victor - I need to review to see it we can implement. No other objections to merging. Will wait for Victor’s review.

WebTransport Bi-weekly Virtual Meeting #61 early - June 6th, 2023

WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m6a263598d572ab9d28d0e96df485d23d EARLY Meeting number (access code): 126 078 4125

Agenda

  • General - TPAC meeting now shifted to Monday Sept 11th at 17:00 CET. Have a request in for Tuesday 12th at same time slot.
  • Issues
    • Priority groups #515
    • Should incomingUni/BidirectionalStreams be "owning"? #507
    • API handling of redirects #499
  • PRs
    • Add getAtomicWriter() API #502

Meeting records

Present: JIB, Will, Randell, Lucas, Harald, Peter, Bernard, Victor,

  • Minutes
    • Meeting was recorded and is available here along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
    • Notes:
      • General - TPAC meeting now shifted to Monday Sept 11th at 17:00 CET. Have a request in for Tuesday 12th at the same time slot.
      • Firefox goes to general release today. #114 - WPT yesterday 547 of 588. Randell submitted fix to AIOQUic to fix greasing problem.
      • Issues
        • Priority groups #515 - Victor - have 2 priority groups, one with sendOrder, the other without. Proposal is to assign to groups, with different sendOrder space. Allows multiplexed flows. JIB - concern that this API would also change default behavior. Victor - not change anything if you don’t use sendOrder. Randell - current spec says unordered streams have higher priority than ordered streams. Harald - if every stream not assigned to a groups given its own group, instead of pooled in to a common group. JIB - breaks how sendOrder today. Current Firefox implementation does not implement fairness between streams of same order. IETF spec says should share. Victor - that is for sessions, not streams. Randell - concerned with telling UA how to implement fairness. Victor - no one has shipped sendOrder yet. JIB - if there are 10 streams in one group and one in another, do the 10 each get an eleventh, or 1/10th of half? Randell - defining what share of the bits you get is very difficult for the implementation. What happens if you remove a stream in the middle of sending? Lucas - not hearing use case that needs specific byte allocations, seems most can get away with some fuzziness. Can implementations test current API. Victor - does not like current setup. Randell - consider separate streams, sendOrder of one is much higher than the other, gets priority over the other. Changes position, now supports proposal. Lucas - weights are too much. Fixed weighting scheme. Group 0 has highest priority, all others are round-robined. Victor - you can not chose to not participate in a priority scheme. There are always defaults. JIB would support priority scheme in which default is to give each flow its own group. JIB - continue on github.
        • Do we need to say something about default priority and fairness?#520 - UA SHOULD be fair in dividing bandwidth between streams. Ready-for-PR.
      • PRs
        • Add automated glass-glass latency calculation via RVFC #519 - uses RequestVideoFrameCallback() to make a better estimate of latency. Sees stratification into two latency buckets. Editors-can-integrate.

WebTransport Bi-weekly Virtual Meeting #60 late - May 23rd, 2023

WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m5904c63dd34fc592c2376e313cf19520 LATE Meeting number (access code): 126 406 0454

Agenda

  • Issues
    • Node.js support for WebTransport #511
    • Can we multiplex more than one session per connection in the same browser tab? #449
    • MAX_STREAM limit #446
    • Should incomingUni/BidirectionalStreams be "owning"? #507
    • API handling of redirects #499
    • Define default send order #493
  • PRs
    • Removing language that indicates the sendRate estimate must be absent when pooled. #514
    • Provide guidance on displaying a human readable error message without language info #513
    • Update normative key words #512
    • Add sendStream.sendOrder = n attribute. #510
    • Make streamErrorCode 32-bit long #509
    • Update BFCache interaction #503
    • Add getAtomicWriter() API. #502
    • Throwing serverCertificateHashes related errors #489

Meeting records

Present: JIB, Will, Bernard, Eric, Nidhi, Victor, David, Lucas, Randell,

  • Minutes
    • Meeting was recorded and is available here along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
    • Issues
      • Node.js support for WebTransport #511 - James is a colleague of Lucas. Intersted in APIs that can work in non-browser environments. He is core contributor to node.js. Hoping to land support once reviews are in. Bernard, can we discuss with him outside of TPAC? Other APIs and features we would want. @Chairs to reach out to James.
      • Can we multiplex more than one session per connection in the same browser tab? #449 - Eric, are we helping people achieve anything, or giving the illusion of control? With pooling, we want a pooled connection to be indistinguishable from non-pooled. Bernard, adding this increases complexity without delivering meaningful improvements. Closed with comment. Might be worth gogin over this reply at IETF117 for AVTCore.
      • MAX_STREAM limit #446 - Randell, if you have a maximum, need to give applications some way to find the max. Bernard, doing frame-per-stream is the problem. Randell, we flush streams but not at new stream creation time, so client keeping count might fail. If set limit, then need to give client clear error message. Also need a way to increase limit. Lucas- from QUIC perspective, there is always a limit. Client needs to ask server for more streams. Randell - we need 1) ability to client to ask for more streams and 2) if none available, rejected in an identifiable way. Eric - supports (2). Would prefer to ask for how many you think it can use. JIB - could we expose stream credits available. Lucas - that ID you get in connection establishment can change. UA should know how many streams can be opened. David - lot of complexity. Good to have feedback, but don’t have API to set. Randell - UA should not be limiting stream count. Need PR to reject things in an identifiable way instead of waiting when MAXLIMIT is reached. David- could also have an event of limit reached, but keep stream creation open. Randell - prefer 1st.
    • PRs
      • Removing language that indicates the sendRate estimate must be absent when pooled. #514 - Bernard - have we asked for a privacy review? @Chairs - ask W3C contact. Merged.
      • Provide guidance on displaying a human readable error message without language info #513 - merged.
      • Update normative key words #512 - JIB, are there lower case musts? Found one. Also ‘should’. Editor’s Let’s avoid lowercase if possible to avoid confusion. Merged.
      • Add sendStream.sendOrder = n attribute. #510 - Martin - could describe with two values, Randell, not necessary and a bit confusing. Reviewed and merged. Merged.
      • Make streamErrorCode 32-bit long #509 - based on change at IETF. No objections. Merged.
      • Update BFCache interaction #503 - Randell, Eric LGTM. Nidhi, need HTML PR 9217 . Need developer interest to land in Chrome. JIB added comment that Mozilla is interested. Merged 503.
      • Add getAtomicWriter() API. #502 - feedback from Martin , what should app do if an atomic write fails? Might be good to have info about how much data I could send. Could return the number of bytes that were written. Bernard - do we have an example about how you would recover from an error.. JIB, you are blocked due to flow control. Bernard - wouldn’t send estimate reflect that? Nice if you could get rwnd back. Let it sit for now until we get more feedback.
      • Throwing serverCertificateHashes related errors #489 - Martin left comment, Victor replied. Eric - reasonable that it should remain as-is, versus a substep. Eric left comment to this effect. Merged.

WebTransport Bi-weekly Virtual Meeting #59 early - May 9th, 2023


WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m6a263598d572ab9d28d0e96df485d23d EARLY Meeting number (access code): 126 078 4125


Agenda

  • General - the meeting time slots for TPAC in Seville are fixed at 09:30-11:00, 11:30 - 13:00, 14:30 - 16:30 and 17:00-18:30. Given that the majority of our attendees will be remote, we selected the least worst time-slot as 14:30 - 16:30 and requested either Tuesday 12th Sept or Thursday 14th as the date. The local times for you all can be found here.
  • Issues
    • Should incoming Uni/BidirectionalStreams be "owning"? #507
    • API handling of redirects #499
    • Define default send order #493
    • MAX_STREAM limit #446
  • PRs
    • Update BFCache interaction #503
    • Add getAtomicWriter() API. #502
    • Throwing serverCertificateHashes related errors #489
    • Support BYOB Readers for Datagrams #487
    • Add .gitignore to remove index.html #504

Meeting records

Present: JIB, Will, Bernard, Peter,

Insufficient quorum, we spent the time discussing issues and PRs relevant to the attendees.

  • Minutes
    • Meeting was not recorded. No decisions were made and all issues were deferred to next meeting.
    • General - the meeting time slots for TPAC in Seville are fixed at 09:30-11:00, 11:30 - 13:00, 14:30 - 16:30 and 17:00-18:30. Given that the majority of our attendees will be remote, we selected the least worst time-slot as 14:30 - 16:30 and requested either Tuesday 12th Sept or Thursday 14th as the date. The local times for you all can be found here.
      • WebRTC are having extended meeting the week after TPAC. Should we do the same? JIB - we might want to get out there and show off WT a little bit. Bernard - misconceptions are high about WT. Peter - if there was a place you could have a simple server code. Bernard - a Node module would help experimentation and adoption. Bernard - may be issue with TLS1.3. Bernard - will look into it and come back in next meeting. See https://github.com/nodejs/node/issues/38478, https://github.com/nodejs/node/pull/44325. Once we have QUIC in Node, then easy to get to WT. Not seeing any support for WT in nginx. MoQ demo from Meta - Jordi is caching objects in the relay. Allows selectable latency, including VOD and clipping.
      • Firefox implementation - passing 505/565 WebPlatform tests. Edge not showing as green - need to activate test server? Safari - in favor of feature, not in 2023 however likely in 2024.
    • Issues
      • Should incoming Uni/BidirectionalStreams be "owning"? #507 - Bernard, would be nice to have send and receive pipelines in separate threads. JIB - streams have unusual transfer access. Using/abusing the serialization concept as a cloning trick. Allows to create pipes of video frame objects.
      • Support sendRateEstimate for pooled connections #497 - assigned to Peter and Will.
      • MAX_STREAM limit #446 - Bernard, default in Chrome may be 100 for sending, will blow up a conferencing use case . So how would you make it larger? Will - an application hint seems reasonable. Bernard - Google meet has 7x7 grid of live streams. 49 streams at 30fps is 1470 WT streams in flight. JIB - is Chrome limit to send or receive? Bernard - any direction. We could write a test app that tests this limit.
    • PRs
      • Add sendStream.sendOrder = n attribute. #510 - can change while stream is in progress. Peter - change to say it should apply as soon as possible. JIB - could say that once write has started, sendOrder at start should persist. Is there a use-case for changing sendorder over time?
      • Add getAtomicWriter() API. #502 - Peter- reviewed and seems like good direction.

WebTransport Bi-weekly Virtual Meeting #58 late - April 25, 2023

WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m5904c63dd34fc592c2376e313cf19520 LATE Meeting number (access code): 126 406 0454

Agenda

  • Issues
    • Define default send order #493
    • Determine interaction with back forward cache #326
    • API handling of redirects Discuss at next meeting #499
    • Support sendRateEstimate for pooled connections #497
    • MAX_STREAM limit #446
  • PRs
    • Throwing serverCertificateHashes related errors #489
    • Support BYOB Readers for Datagrams #487
    • Networking privacy considerations #485

Meeting records

Present: Will, Bernard, Nidhi, Lucas, Eric, JIB, Victor, Martin,

  • Minutes
    • Meeting was recorded and is available here along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
  • General - for TPAC in Seville, very few going. Do we need to use of the CET meeting times? People pay a fee to join the online? @Chairs to ask W3C.
  • Issues
    • Define default send order #493 - JIB new ASCII drawing :). Allows 2GB file upload to be sent along side stream-of-streams. Victor - get complexity of flows (ordered, unordered) without benefits. JIB - sender can figure out how may flows there are by looking at sendOrder numbers. Victor - is dubious of current API. Eric - what is concern? Victor - have to opt everything in, want to set high order so a send is not bandwidth shared. Bernard - do we have use-cases that we need to solve? Control channel is a valid one. JIB - can we file a new issue? Current issue is too long. @Victor - yes, will file a new issue.
    • Determine interaction with back forward cache #326 - merged PR.
    • Support sendRateEstimate for pooled connections #497 - Martin, reluctant to make info available to website as other things using that connection. Server can observe all of the same things. Bernard - issue is about other tabs on the client. You should not be able to pool WT connections with other tabs. Browser should not pool webtransport connections across tabs. No worse than exposing CWIND. No huge risk of leakage. Martin - we should remove checks and simplify spec.
  • PRs
    • Throwing serverCertificateHashes related errors #489 - Victor approved. @Martin to review.
    • Support BYOB Readers for Datagrams #487 - note to check with @Randell. Editors-can-integrate.
    • Networking privacy considerations #485 - Nidhi, question, do we need to add HTML or just bikeshed? JIB - just bikeshed. Editors-can-integrate, remove html before merging.
    • Specify BFCache interaction #500 - JIB - are Chrome interested in implementing this? @Nidhi - Chrome expresses interest.Has integration error - Bernard resolved. Not an issue with the PR. Merged.
    • State persistence #501 - Bernard, concern about fingerprinting. Martin - QUIC is not special, session tickets same as TLS, should strike last 3 lines. Merged.
    • Add getAtomicWriter() API. #502. - under construction. Returns a boolean in the promise if atomic write was successful. May be an issue with Streams if it receives a promise without undefined. Martin happy if Streams is happy. Bernard - need a test with large objects. Lucas - could cause problem if flow-control blocked. Martin - do we put something in API to let sender know when write failed? Another attribute might be useful to help applications know what to do with a ‘false’ response.

WebTransport Bi-weekly Virtual Meeting #57 early - April 11, 2023

WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m6a263598d572ab9d28d0e96df485d23d EARLY Meeting number (access code): 126 078 4125


Agenda

  • General
  • Issues
    • Should there be any way to send capsules on the WebTransport session CONNECT stream? #496
    • Define default send order #493
    • Allow updating send order for streams #492
    • Does sendRate drop if I stop sending? #476
    • MAX_STREAM limit Discuss at next meeting #446
  • PR's
    • Add estimatedSendRate to stats #494
    • RESET_STREAM handling #491
    • Throwing serverCertificateHashes related errors #489
    • Support BYOB Readers for Datagrams #487
    • Networking privacy considerations #485

Meeting records

Present:

  • Minutes
    • Meeting was recorded and is available here along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
    • Notes:
  • General
    • Jordi (Meta) demo server allows relay interop testing
    • Youtube video of "WebTransport Low Latency Demo"
    • Encoder & Player Code is on GitHub
    • Server/Relay code is also available
    • TPAC Attendance (online): Randell, Bernard, Peter, Jan-Ivar, Victor
  • Presentation at IETF 116 WEBTRANS meeting - got feedback on 4 issues
  • PRs
    • Issue 484/PR 494: Add estimatedSendRate to stats - If the method is pooled you don't get a value. Peter proposes merging now, discuss pooling in a separate issue. No objection to this approach. Meeting note: Merging this and filing a new issue to discuss pooling. Created new issue 497: Support sendRateEstimate for pooled connections
    • PR 491: RESET_STREAM handling - Eric Kinnear had editorial suggestions. Merging them.PR Merged.
    • PR 489: Throwing serverCertgificateHashes related errors - Victor to provide comments.
    • PR 487: Support BYOB readers for datagrams - 2 approvals. Randell Jessup to review. Is Kagami good with it? Ping to saschanaz: Are you happy with this PR or are there remaining issues?
    • PR 495: Networking privacy considerations - Victor to take a look
  • Issues
    • Issue 496: Should there be a way to send capsules with the Webtransport Connection Stream? Victor: I see a reason to not do this. Capsules can be used for nested flow control. If the API would allow applications to send things different from what the browser knows to be true that would be "moderately concerning". Bernard: I had the same reaction: potential security issue.
    • Issue 493: Define default send order - Victor: Currently we say the send order is a UInt64. Proposal to simplify is that the default order is always 0. If things are different, higher order goes first. Jan-Ivar: my pushback is that we already decided to have it this way. Reason is that it allowed for other flows. Victor: I'm not sure I understand your concern. Jan-Ivar: Meeting notes from December are in the GitHub thread. Victor: If you have opinions about order, you should be applying them globally to everything in the connection. Valenting comment in thread: "The solution is to treat streams with no sendOrder as having the same priority as highest send order." Victor: incredibly difficult to implement. Randell: We're working on sendOrder right now. Valenting's proposal doesn't seem particularly more complex. Jan-Ivar: maybe we could share implementation notes. Victor: I could implement it, I just find it unnecessary. Meeting notes: no agreement. Implementers encouraged to share notes on implementation difficulties.
    • Issue 492: Allow updating send order for streams - Victor: this one is much simpler. Suggestion to add an updateSendOrder() method. Randell: Clearly we need this. Jan-Ivar: Next step is bikeshedding on API. Do we want to have a narrow solution? Simple to do it in the constructor. If we add stream.priority = n would it work on every type of stream? Randell: That's what I would suggest. Keeps the API regular. Jan-Ivar: Any other proposals? No other good alternatives come to mind. Marked "Ready for PR"
    • Issue 476: Does sendRate drop if I stop sending? Most questions resolved by PR 494. Bernard: Doesn't it depend on the CC algorithm? There is a history of support for rate decay. Peter: Getting back to the original question... it does depend on the algorithm. If you support probing then you don't have to do decay. Randell: In general knowledge, state of the connection becomes fuzzy over time. Bernard: Conclusion is you can't mandate behavior in the spec. Randell: Depends on internals we don't want to model in the spec. Peter: We could put something in... perhaps a warning? Hard problem here! Randell: Value may not be correct if you haven't been sending.
    • Issue 446: MAX_STREAM limit Bernard: Did IETF 116 WEBTRANS discussion indicate the need for an API surface? Randell: If you are negotiating, there can be issues. Client asks, but server might not agree. Bernard: If the issue is with server sending to client, do we need an API surface? Server can't know ahead of time how many participants there are/how many streams. Randell: If the server is sending there's no need for an API surface. If the client is sending it is an issue for the API. Under what circumstances is this limit making things better for the implementer or user. Lucas: Limit helps prevent resource exhaustion. An API can help by giving server more credits. The other way around requires a discussion with IETF. Lucas: We need an API that would tell client to send more MAX_STREAM credits to the server, to allow more incoming streams to the client. To allow more streams from client to server we need help from the IETF. Bernard: how does the client know how many streams might be sent by the server? User attends a webinar. Will a million people be attending the webinar or only a few? How can the client know what MAX_STREAM credits are needed??

WebTransport Bi-weekly Virtual Meeting #56 early - March 14, 2023


WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m6a263598d572ab9d28d0e96df485d23d EARLY Meeting number (access code): 126 078 4125

Agenda

  • General - who might attend W3C TPAC in Seville Sept 11-15 in person or online? We are trying to select the least-worst time slots early.
  • Issues
    • Add sendRateEstimate to getStats() #484. - check in with Peter.
    • Does sendRate drop if I stop sending? #476
    • MAX_STREAM limit Discuss at next meeting #446
  • PRs
    • Support BYOB Readers for Datagrams #487
    • Editorial reference updates #486
    • Networking privacy considerations #485
    • Receiving a DRAIN_WEBTRANSPORT_SESSION capsule #482

Meeting records

Present: Will, Bernard, Peter, JIB, Victor, Randell

  • Minutes
    • Meeting was recorded and is available here along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
    • General
      • Firefox, nightly 113, turn WT on by default March 15. For relay testing, can Jordi MoQ server be used. @Bernard - can we get Janus to support WebTransport?
      • Who might attend W3C TPAC in Seville Sept 11-15 in person or online? We are trying to select the least-worst time slots early. Results - everyone remote except Will.
    • Issues
      • Add sendRateEstimate to getStats() #484. - check in with Peter. @Peter - two parts, ok with removing event, but for stats, do we want app logic to depend on Stats, or debugging? Victor - stats are already dependable. Stats may not be the best name, more like transport state. Some are for debugging, but some are actionable. @JIB, WebRTC has targetBitrate. getStats() is a historical name. Benefit is that we move it to an async() method, so UA does not have to update unless user requests. Seemed better to have a new PR. @Peter - will accept new PR.
      • Does sendRate drop if I stop sending? #476 - does sendRate drop if I stop sending? @Randell - estimate sendRate becomes uncertain if you don’t send. If you are measuring rate at which you have been sending, hard to define if you are not sending. @Victor - useful number would be bandwidth based on state of congestion controller cwnd/rtt, or rate limit. This is the guess at how fast the congestion controller can send. Congestion controllers try to avoid dropping throughput between bursts. Randell - should be rate at which congestion controller expects to be able to send when you resume sending. Peter - defined as rate to send to avoid queuing. Can rate grow above what it is if you are not sending? Randell - concern about avoiding queuing, overly strong statement. Bernard - sendRate is used to decide on target bitrate. Peter - if you have two pooled connections, have a privacy concern - side effect, inspect. JIB - can send rate turn to null at any point. Victor - once non-null it should stay non-null. Privacy concern some browsers would have a bw estimate that is a carry-over from previous connections. We should be careful about exposing that. Also stats get reset on a connection migration. Randell - what to return if connection is in an error state? JIB - zero.
      • MAX_STREAM limit Discuss at next meeting #446 - not discussed.
    • PRs
      • Support BYOB Readers for Datagrams #487 - no objections to supporting BYOB readers. Bernard - I can contribute an example of BYOB for streams. @Randell to review, then can merge.
      • Editorial reference updates #486 - no objections, merged.
      • Networking privacy considerations #485 - Bernard reviewed. Victor - would like to review. Deferred.
      • Receiving a DRAIN_WEBTRANSPORT_SESSION capsule #482 - did modify to add support for goaway frame in addition to capsule. No objections. Merged.
      • Throwing serverCertificateHashes related errors #489 - Victor, I reviewed this. Seems to be in the wrong place, but no better place. Also concerns for error response. Victor will write a comment. Deferred.
      • RESET_STREAM handling #490 - added non-normative note, copied form 3.2 of QUIC spec. Bernard - will you error readable if all data has been received? Victor - stream API does not allow to error a stream that is already closed. @Victor to review. Deferred.

WebTransport Bi-weekly Virtual Meeting #55 late - Feb 28, 2023

WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m5904c63dd34fc592c2376e313cf19520 LATE Meeting number (access code): 126 406 0454

Agenda

  • General
  • PRS
    • Add rate control event #421 - comments from Martin
    • Congestion control event with no sub-object #471 opened yesterday by pthatcher
    • Congestion control event with everything in WebTranspsort.rateControlFeedback. #470
    • Use nested steps for steps run in parallel #468 opened 2 days ago by nidhijaju
    • Receiving a DRAIN_WEBTRANSPORT_SESSION capsule #437
  • Issues
    • API behavior when opening a new stream is blocked #469
    • MAX_STREAM limit #446
    • When flow control is blocked #426

Meeting records

Present: Will, JIB, Bernard, Victor, Nidhi, Eric, Randell, Martin,

  • Minutes
    • Meeting was recorded and is available here along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
  • General
    • Randell - basic support for WebTransport in Firefox is in nightly behind config flag!
  • PRS
    • Receiving a DRAIN_WEBTRANSPORT_SESSION capsule #482 - Bernard - do we want to expose goaway as a separate signal? Does app need to know? Future attempts at stream connections will fail. Martin - browser will manage this. We should not surface it to the app. Bernard - can redo PR with goway and drain capsule being addressed by same draining promise.
    • Add rate control event #421 - comments from Martin. See issue discussion.
    • Use nested steps for steps run in parallel #468 opened 2 days ago by nidhijaju - Nihdi - just editorial. Reviewed. Marked Editors can integrate.
    • Supporting "reliable-only" #474 - only talking about first hop. Future hops are not guaranteed. Orig text did not explain this. Martin - reliable will look like bad performance. Bernard - will look quite similar until congestion happens. Martin - lets accept PR. Victor - first hop is where unreliable will have most benefit. Merged.
  • Issues
    • Final API shape of rate control feedback #481 - made by JIB to clarify the differences between rate control API. Martin - important to talk about estimates. Proposed new names - sendRateEstimate and sendRateInterval. Bernard - does prefer dict approach. Martin - stack estimate will update every time an ACK is received. App does not want an event every 3ms. JIB - don’t need event then. Victor - why is sendRate not part of getStats? Bernard - this predicts something whereas other stats are retrospective. Randell - it’s is a prediction based on short term data. Randell - is gathering all stats resource intensive? Martin - no. Consensus to add to stats.
    • API behavior when opening a new stream is blocked #469 - Victor - consensus seems to be we should close with no action. Martin - agree. Performance will tank but we have #446 (request other side for higher stream limit).
    • MAX_STREAM limit #446 - Martin - servers can do what they need ot do to support their apps. Browsers however need to set some sort of default, but not applicable to high framerate video. Need to support the high-stream rate creation rate. Most APIs talk about number of concurrently active streams. JKB - dangerous to make JS API where app can ask for my. Will - why wouldn’t UA just ask automatically? Randell - where is there an advantage of putting in that limit? Simpler if handled behind the scenes. Victor - you don;t always know how many resources you have. Two limits here - one how may streams you can accept in total, other is number of streams buffered in network stack. We should separate those. More concerned about the 2nd one. Victor - I am talking about streams not yet accepted by the application. JIB - can UA adapt to these use-cases without requiring input from app. Victor - as long as app accept new streams. Martin - multiplicative increase may be too slow for an app, so may be value in app asking for 1000 streams up front. Randell - why is limit 100, or 100 and why not 64,000? JIB - need to chew on this.
    • When flow control is blocked #426 - I don’t have a solution. Use of streams API makes this difficult. Only solution is building a parallel piece of writing infrastructure outside of Streams. JIB - need to make sure this use-case exists. Martin - pub/sub most likely to run to this problem. Martin - is sendStream.getAtomicWriter objectionable? No objections. Mark ready-for-PR.

WebTransport Bi-weekly Virtual Meeting #54 early - Feb 14, 2023

WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m6a263598d572ab9d28d0e96df485d23d EARLY Meeting number (access code): 126 078 4125


Agenda

  • General
  • Issues
    • MAX_STREAM limit #446
    • Client initiated drain #436
    • hole punching support #429
    • When flow control is blocked #426
    • expose a TLS Keying Material Exporter / unique value for the TLS session #411
  • PRs
    • Allow ∞ for incoming/outgoingHighWaterMark and incoming/outgoingMaxAge #464
    • Add rate control event #421
    • Align WebTransportError with guidance. #460
    • Rely on allowPooling's default value. #462
    • function name mismatch in sample snippet #461
    • Receiving a DRAIN_WEBTRANSPORT_SESSION capsule #437
    • Add WebCodecs-Echo to the samples directory #430

Meeting records

Present: Will, Peter, JIB, Victor, Randell, Bernard.

  • Minutes
    • Meeting was recorded and is available here along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
  • General
  • Issues
    • MAX_STREAM limit #446 - Victor , it is possible for dedicated connection, might want to provide API to increase limit. Or could report limit in stats object. Chrome is 100 concurrently. Partially concurrency control. Bernard - cumulative or current? While on wire, cumulative, once close. Client might want to raise its limit. JIB - can user-agent automatically ask for more? Might want error code to say we have exceeded number of streams.
    • Client initiated drain #436 - client can only send drain, not goway. Server can send both. With IETF meeting coming up, can ask.
    • hole punching support #429 - a server behind a firewall is effectively a peer. No objections to closing. Closed.
    • When flow control is blocked #426 - need to check with Martin. Defer to later meeting.
    • expose a TLS Keying Material Exporter / unique value for the TLS session #411 - doesn;t sound like its problematic. Some support in meeting. Victor - prefer a prefix to the label. Want to ensure that we don’t overlap with a non-WT exporter. Ready for PR. Assigned to Victor.
  • PRs
    • Allow ∞ for incoming/outgoingHighWaterMark and incoming/outgoingMaxAge #464 - also covered negative values and 0. Double -> unrestricted double. Merged.
    • Add name to Editors list #465 - adding Nidhi as editor. Merged.
    • Update protocol mapping table #467 - editorial. Merged.
    • Use nested steps for steps run in parallel #468 - W3C guidance. Editorial. Need reviewer before merging.
    • Add rate control event #421 - Peter - merged all changes, made two new PRs #470 and #471. Discuss API shape on github.
    • Align WebTransportError with guidance. #460 - breaking change for Chrome, but accepted by Adam. Brings spec into alignment with W3C guidance. No objections. Bernard - does this need a test? Will add a needs-test label. Merged.
    • Rely on allowPooling's default value. #462 - web idl nits. Merged.
    • function name mismatch in sample snippet #461 - non substantive. Merged.
    • Receiving a DRAIN_WEBTRANSPORT_SESSION capsule #437 - Bernard, rewrite to use goaway frame. Victor - both are valid mechanisms. Drain is specific to session. Goaway is for entire H3 connection. We should support both signals.
    • Add WebCodecs-Echo to the samples directory #430 - bernard - working, so lets add. Generally have been removing awaits. Code is useful to others. Will continue to clean it up over time. Merged.

WebTransport Bi-weekly Virtual Meeting #53 early - Jan 17, 2023

Date/Time: Click here for Local Times EARLY


WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m6a263598d572ab9d28d0e96df485d23d EARLY Meeting number (access code): 126 078 4125

Agenda

  • General
    • Rechartering - approved at AC meeting and underway. Prior charter ran from 9/20 - 9/22. New charter expiration will be Sept 2024. See https://www.w3.org/2020/09/webtransport-wg-charter.html for details.
    • TPAC 2023 dates and location have been finalized - Seville , Spain 11-15 September 2023.
  • Issues
    • Allow datagram send order relative to streams to be application defined #451
    • Handling of negative values and 0 for incomingMaxAge #450
    • Can we multiplex more than one session per connection in the same browser tab? #449
    • MAX_STREAM limit #446
    • Client initiated drain #436
    • When flow control is blocked #426
    • Consider aligning WebTransportError with upcoming guidance #425
    • Clarify DOMString comparison method in dictionaly WebTransportHash #413
    • expose a TLS Keying Material Exporter / unique value for the TLS session #411
  • PRs
    • Restore #380 after merge accident. #455
    • Update index.bs to clarify DOMString comparison method #453
    • Receiving a DRAIN_WEBTRANSPORT_SESSION capsule #437
    • Add WebCodecs-Echo to the samples directory #430
    • Add rate control event #421

Meeting records

Present: Will, JIB, Lucas, Randell, Harald, Peter, Victor

  • Minutes
    • Meeting was recorded and is available here along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
  • General
    • Rechartering - approved at AC meeting and underway. Prior charter ran from 9/20 - 9/22. New charter expiration will be Sept 2024. See https://www.w3.org/2020/09/webtransport-wg-charter.html for details.
    • TPAC 2023 dates and location have been finalized - Seville , Spain 11-15 September 2023.
  • Issues
    • Allow datagram send order relative to streams to be application defined #451 - JIB meant to be a single number for all datagrams. Lucas - will need to be solved in future when people create apps. One value for datagrams compared to streams would be fine. Can sendOrder change . JIB - no one prioritizing datagrams over other Lucas - outside WT world, in masque world would want separate datagram control. IETF is chartering new work for different priorities for datagrams. If you could specify order with each write, then could satisfy future masque-like cases. Victor - we could make multiple flow objects in future for datagrams. No main objections - ready for PR.
    • Handling of negative values and 0 for incomingMaxAge #450 - marked ready-for-PR.
    • Can we multiplex more than one session per connection in the same browser tab? #449 - Peter - JIB’s not about require pooling would be sufficient. Not hearing immediate interest. Moved to future milestone.
    • MAX_STREAM limit #446 - skip since martin/bernard to present.
    • Client initiated drain #436 - Victor, will need to read more carefully.
    • When flow control is blocked #426 - JIB proposed a new API for an atomic writer. Peter had proposal for allocate write space. Discuss at next meeting when Martin present.
    • Consider aligning WebTransportError with upcoming guidance #425 - changes order for constructor arguments. Breaking change. Victor - ok as long as Adam approved. No objections. Ready-for-PR.
    • Clarify DOMString comparison method in dictionaly WebTransportHash #413 - closed with PR #453.
    • expose a TLS Keying Material Exporter / unique value for the TLS session #411 - discuss with Martin.
  • PRs
    • Restore #380 after merge accident. #455 - clean up-from merge error. Merged.
    • Update index.bs to clarify DOMString comparison method #453 - Harald - is this a change for an implementation? Merge with note that its needs test. Victor, no objection and will check. Harald - it is a straight string compare currently.
    • Add rate control event #421 - updated based on prior meeting feedback. Change name to ratecontrolFeedback, back to an interface rather than a dictionary and notes in privacy section about pooling. JIB - rate in bits versus bytes? WebRTC uses bits per second. JIB - value should hang directly off WT. Randell - rate is dependent . Harald - outgoing buffer size would be useful. No significant objections. Victor will review. Peter - some issue with bikeshed - harald - likely due to a dead reference. JIB - spec should define ratecontrolfeedback, not just the onratecontrolfeedback event handler which are separate things. WebTransport object does not sub-class event Target. Editors-can-integrate.

Meeting template

WebTransport Bi-weekly Virtual Meeting template

WebEx Access

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m6a263598d572ab9d28d0e96df485d23d EARLY Meeting number (access code): 126 078 4125

https://webtransport.my.webex.com/webtransport.my/j.php?MTID=m5904c63dd34fc592c2376e313cf19520 LATE Meeting number (access code): 126 406 0454

Agenda

  • Item
  • Item
  • Item

Meeting records

Present:

  • Minutes
    • Meeting will be recorded and available [Link here] along with a full transcript. The password for access was distributed via the members-only mailing list. If you require it, please contact your chairs.
    • Notes:
      • Item
Retrieved from "https://www.w3.org/wiki/index.php?title=WebTransport/Meetings2023&oldid=117144"