Agenda, time update (half an hour shorter)

[Michael Welzl]

Hi everyone,

Some updates:

First, note, the side meeting is now shortened, from 18:30 to 19:30, to avoid an overlap with a following side meeting on “TCP_REPLENISH_TIME”  (organized by Stuart Cheshire, who was nice enough to delay the beginning of his own meeting by half an hour).  One hour should be enough for us, I believe.

Second, I have created an agenda on the github page: https://github.com/mwelzl/oppd and in our slides.

This agenda is very simple:

- 15 min presentation by me, just to explain what this is about and frame the discussion,

- 45 min discussion on:

  1. where should this work happen,

  2. where should the following work happen (on performance-enhancing network functions),

  3. (if time permits:) a tech. discussion of the actual approach.

I think item 3. is less important than the others: the answer to item 1 is likely “scone” ?!  well we’ll see… but once we have a home, this is where the detailed design discussion can take place.

Item 2 is the big question mark for me, and I think it would be good to invest time into figuring this out.

Thoughts?

Cheers,

Michael

[Joerg Ott]

Hi Michael,

it's good have the implicit assumption _that_ the work should happen in
the IETF and not even put this up.

Do we need to answer the question how (well) we fit into the web config
ecosystem? A tentative aspect to keep in mind that, while MASQUE
decided to use H3 for signaling, not all uses of QUIC as a transport are
the web, even though I see more and more evidence inside the QUIC
community of this being one assumption. One example that came up in
QUIC in this morning is the P2P QUIC that is meant for generic transport
overlays (all inside QUIC) but then uses MASQUE and hence H3, which
seems acceptable there.

Cheers,
Jörg

On 06.11.24 11:07, Michael Welzl wrote:
> Hi everyone,
>
> Some updates:
>
> First, note, the side meeting is now shortened, from 18:30 to 19:30, to
> avoid an overlap with a following side meeting on “TCP_REPLENISH_TIME”
>  (organized by Stuart Cheshire, who was nice enough to delay the
> beginning of his own meeting by half an hour).  One hour should be
> enough for us, I believe.
>
> Second, I have created an agenda on the github page: https://github.com/

> mwelzl/oppd <https://github.com/mwelzl/oppd> and in our slides.

>
> This agenda is very simple:
> - 15 min presentation by me, just to explain what this is about and
> frame the discussion,
> - 45 min discussion on:
>   1. where should this work happen,
>   2. where should the following work happen (on performance-enhancing
> network functions),
>   3. (if time permits:) a tech. discussion of the actual approach.
>
> I think item 3. is less important than the others: the answer to item 1
> is likely “scone” ?!  well we’ll see… but once we have a home, this is
> where the detailed design discussion can take place.
> Item 2 is the big question mark for me, and I think it would be good to
> invest time into figuring this out.
>
> Thoughts?
>
> Cheers,
> Michael
>

> --
> https://github.com/mwelzl/oppd <https://github.com/mwelzl/oppd>
> ---
> You received this message because you are subscribed to the Google
> Groups "oppd-ietf" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to oppd-ietf+...@googlegroups.com <mailto:oppd-
> ietf+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/oppd-
> ietf/6E2834CA-E282-4EC0-A43D-5A7A924DE681%40ifi.uio.no <https://
> groups.google.com/d/msgid/oppd-ietf/6E2834CA-E282-4EC0-
> A43D-5A7A924DE681%40ifi.uio.no?utm_medium=email&utm_source=footer>.

[Michael Welzl]

Hi,

> On Nov 6, 2024, at 12:41 PM, Joerg Ott <o...@in.tum.de> wrote:
>
> Hi Michael,
>
> it's good have the implicit assumption _that_ the work should happen in the IETF and not even put this up.

I have that assumption: my slides only ask “where”, not “if” - I can rephrase to: “where in the IETF” if that helps….
Or are you objecting to one of my 3 agenda items - are you suggesting to remove one?

> Do we need to answer the question how (well) we fit into the web config ecosystem? A tentative aspect to keep in mind that, while MASQUE decided to use H3 for signaling, not all uses of QUIC as a transport are the web, even though I see more and more evidence inside the QUIC community of this being one assumption. One example that came up in QUIC in this morning is the P2P QUIC that is meant for generic transport overlays (all inside QUIC) but then uses MASQUE and hence H3, which seems acceptable there.

Hm. I don’t know.

Cheers,
Michael