Canceling Wednesday's meeting

Hi multicast-cg,

I fractured my shoulder and knee last Friday. (I was climbing
what I thought was a stepstool, but was actually a dog ladder
that couldn't support my weight, and it broke under me.)

Because of that, I missed some prep time this weekend and might
have some new conflicts this week as the doctors take a look,
so I'm going to cancel this Wednesday's meeting.

But to give a few updates:

- I sent the secdispatch update, but got no discussion yet on msec:
  https://mailarchive.ietf.org/arch/msg/secdispatch/MCvt8J6-XfJw47TKslaRl2YNqbs/

  https://mailarchive.ietf.org/arch/msg/msec/FYx5GsAtAyI3pypPIlJ_s3vtiwc/


- The internal efforts to get some deployment without waiting for
  standards updates were active enough to pull me away from some of
  the time I'd hoped to spend on the quic effort, but there are still
  a few updates there:
  - I did some experimenting with chromium and webtransport wpt tests.
    I don't think that's fully baked right now, so I think getting
    something running under quiche (https://github.com/google/quiche)
    and then aioquic (https://github.com/aiortc/aioquic) is the right
    place to be looking first.
  - I did some more detailed reading on the relevant quic drafts:
    https://www.ietf.org/archive/id/draft-lmbdhk-quic-multipath-00.html

    https://www.ietf.org/archive/id/draft-pardue-quic-http-mcast-09.html

    I think the multipath spec with the "multiple PN spaces" can be a
    good approach, though there would have to be some important
    differences.  But to the client I think this can look very similar
    to a multipath QUIC connection for a unidirectional stream from the
    server.  Still moving this direction, but prioritizing things likely
    to lead to deployment without browser support, as we discussed last
    time.

Also noticed I forgot to post last month's video, but it's up here now:
https://youtu.be/StMuMXMRYxQ


See you next month.

-Jake

Received on Tuesday, 1 February 2022 06:08:41 UTC