Re: New Version Notification for draft-huitema-quic-mpath-req-00.txt

[Martin Thomson <[e-mail]>]

With the notice here that we're probably getting ahead of things a little...

On Tue, Jan 2, 2018 at 3:32 PM, Christian Huitema <[e-mail]> wrote:
> Actually, flow control in TCP is used both as an application layer tool, e.g. don't send faster than the printer can print, and as a transport level tool to limit the speed at which the peer can send. If we just look at the application level, then of course this is purely a stream layer issue. But if we consider the transport function, then it makes sense to tie it to a path.

I'm not sure that I see the logical connection here.  If the intent is
to govern send rate on a given path, then we probably want a different
mechanism, but it's not really flow control any more.  I think that
our TCP heritage might be more of a liability in this case and we
should be clear what properties we're seeking - plus some new names
for these functions.

>> I'm going to have to think on it some more, but your suggestion in 4.7 might be a good idea.  We don't have to do that now, though we might choose to do so if we can work through the design and implications.
>
> Either separate encryption keys for separate connection ID, or mix IV with connection ID and sequence number for the nonce. The latter might work better, because it does not require keeping the master secret around. But it leaks one bit for correlation if the phase bit changes at the same time on all paths after a key rotation.

A simpler design has a key rotation for every connection ID change and
no key phase bit.  There are a few downsides of course, but those can
be managed.