Re: Fwd: New Version Notification for draft-liu-multipath-quic-01.txt

[Christian Huitema <[e-mail]>]

On 12/14/2020 11:38 AM, Mikkel Fahnøe Jørgensen wrote:
>
>> It boils down to how much additional state you want to maintain in or 
>> to support multipath. The 32 bit constraint allows for a very simple 
>> implementation. I don't think applications are going to hit it in 
>> practice. Supposing one connection migration per second, the limit is 
>> not hit for one hundred years.
>>
> Counting on fingers … hmm well yeah 136 to be exact. And for space 
> travel you can’t even migrate that fast, but then 100 years might mean 
> something else.
>
> I still don’t like modifying the underlying semantics and I’m also a 
> bit concerned about the path sync issue, especially on forward 
> stations / offloads.
>
I am really not sure about the "underlying semantics" argument. We have 
hidden limits in the current design. For example, the MAX_DATA frame 
encodes the Maximum Data as a varint, thus no more than 2^62 bytes can 
be sent on a connection. Given a minimum MTU size of 1200 bytes, that 
means connections are unlikely to send more than 2^52 packets. That is a 
practical limit over all flows combined when using multipath. AEAD 
encryption imposes other limits, including limits on number of 
decryption failures that cannot be mitigated by key updates. The reality 
is that QUIC connections are not designed to last forever.

-- Christian Huitema