Re: [quicwg/base-drafts] What can change in a different version (#55)

[Mirja Kühlewind <[e-mail]>]

(I just saw that when I simply reply directly to an email it doesn’t show my email-address as sender. The mail below was from me. Mirja (Kühlewind))

> Am 16.12.2016 um 22:32 schrieb QUIC WG Issues Account <[e-mail]>:
> 
> Just one additional thought: If you use the connection id for load balancing I assume you use the port number as an indication that you actually look at a quic packet that is encapsulated in UDP. I guess if you see the version number also as some kind of magic number (and apply some care in selecting your version number to not use a bit pattern that is already used by a different protocol over udp), you would get some additional confidence that you actually look at a quic packet. Not sure if that is worth is or if this is a good idea at all but might at least be worth thinking about it.
> 
> 
>> Am 14.12.2016 um 15:56 schrieb ianswett <[e-mail]>:
>> 
>> Yes, clearly the version bit must not change. And I think it's fine to always have the client use a 64 bit connection id until negotiated, but I think there were a few folks interested in suggesting 128 bit connection ids for future connections. If that becomes a requirement, then putting the version before the connection id may be the way to go?
>> 
>> The benefit of the current approach where the connection ID directly follows the flags is it's easy for load balancers to deal with. That being said, if they're going to have to deal with an extended flags bit, the extra complexity of dealing with a connection id that comes after the version may not matter.
>> 
>> And I do think the MORE_FLAGS bit should be defined. The alternative would be to not use more than one flag byte until after version negotiation is complete, but that may be sub-optimal.
>> 
>> —
>> You are receiving this because you are subscribed to this thread.
>> Reply to this email directly, view it on GitHub, or mute the thread.
>> 
> 
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub, or mute the thread.
>