[Idr] my comment on mike quic fsm stuff

[Tony Przygienda <[e-mail]>]

As I said on the mike, my decently extensive experience is that at the
level of complexity the draft aims at trying to keep the FSMs specified in
tools, be it UML pictures or some kind of EBF syntax becomes super fragile,
especially since you can count on good amount of mildly suprising effects
when dealing with QUIC ;-)

The safest way to make sure this draft doesn't generate significant amount
of follow up work and interoperability problems in the field is to provide
a reference implementation on top of highly formalized FSM library that an
implementation can test against and the library is capable to generate SVG
pictures, table formats of actions etc automatically

Recently published work that may help you with that is either a Rust
library juniper open sourced

https://crates.io/crates/extfsm

which all the Rust RFC is based on

or alternately the FSM library implementation in python contained in

https://github.com/brunorijsman/rift-python

which also contains an extensive framework of tests as good example how to
run two implementations against each other and assure interoperability

as another interesting input, you probably want to nail the version of QUIC
used fairly strictly for interoperability purposes. It's pretty stable
since about 2-3 years but there have been surprises on updates and since
you use channeling extensively, that can change behavior/performance quite
drastically depending how it's used within an implementation as well

Easy? No, lots of work but IME this guarantees a very high quality (as in
correctness and robustness) deliverable as specifications go at this level
of complexity and impact ...  Observe that the performance of the whole
thing is irrelevant largely. exchanging bunch of routes on AF is surely
good but e'thing else is implementation really (still modulo QUIC
subchannel behavior)

thanks & my 2c

-- tony