Testing the proposed PRs in a timely fashion

[Christian Huitema <[e-mail]>]

There are a couple of PR in the queue that could bring big changes to
transport implementations: the proposed changes in the Connection ID
from 8 to 17 bytes; the proposed encryption of packet numbers; the
extension mechanism; and the proposed redefinition of the migration
mechanism. Such changes are very likely to require interop testing, both
to verify that the specs work as proposed, and to find and correct
implementation bugs. That will take time. I am also worried that if we
check in all these PR at once, we will destabilize the implementations.

My proposal is to pick some but not all of these PR and integrate them
in the next iteration of the transport draft, so we can start interop
testing. If I had to start somewhere, I would start with the path
migration PR. It seems close to ready, it requires significant coding,
and it replaces the PING/PONG mechanism that we would rather forget and
not implement. Path migration also requires some testing infrastructure,
such as opening multiple sockets on the client and migrating the
connection from one to the other. Not hard to do, but requires some time
to get it right, so the sooner we start the better.

What do other developers think?

-- Christian Huitema