Subject: Testing the proposed PRs in a timely fashion

From: Christian Huitema <[email-masked]>
Date: Mon, 26 Feb 2018 11:19:49 -0800

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 27 Feb 2018 09:57:25 +1100

The 17-byte thing seems unlikely to be adopted.  Based on the outcome
of the design team discussion, a double connection ID mechanism is
more likely.

As for merging, I think that we are close to merging the migration PR.
It's mostly editorial issues that are holding it back now.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 26 Feb 2018 15:50:52 -0800

> of the design team discussion, a double connection ID mechanism is

Yes. But then moving to double connection ID of variable length is also
going to require serious development and testing effort. To evaluate
that, I changed the "connection_id" type in Picoquic from uint64_t to an
opaque type. This was not simple, since the connection ID is used pretty
much every where, not just in protocol code but also in logging code,
test code, and of course test vectors. And doing that caused a couple
regression bugs, which I only found weeks later. Of course I am sure
that other developers can do it better, but still, they will need time
to work it out.  If we want to be done in November, we may want to test
that kind of stuff sooner rather than later.
> It's mostly editorial issues that are holding it back now.

Cool. Do you think we could have that spec merged before the London
meeting? Or should we start preparing for interop days in April and May?

-- Christian Huitema

---

From: Martin Thomson <[email-masked]>
Date: Tue, 27 Feb 2018 11:05:25 +1100

> meeting? Or should we start preparing for interop days in April and May?

I hope so.  That depends a little on Jana though.  I've been holding
-10 for it, because it seems like a good thing to put into something
more concrete.

I would prepare for more interop days no matter what.  I'm not yet
confident that we're at the point of people deploying code and until
that happens, these events are what we've got.

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 27 Feb 2018 13:56:49 -0800

> -10 for it, because it seems like a good thing to put into something

I've been in a bit of a lull the past week, but climbing out of it now. I
am hoping to address comments on the PR today, and I think there's enough
momentum in the wg to get it to merge soon. That said ...

> that happens, these events are what we've got.

... I agree with this. We have a number of moving pieces, and -10 isn't the
end of it. The more interops we have, the faster we move towards spec
maturity, which we sorely need.