Draft: draft-ietf-quic-applicability

Commentary: addresses ( partially at least ) 
 The text says : “ or prime the congestion controller in preparation for switching to the new path . ” what does prime mean ? and which section explains this function in the QUIC spec ? 
 The idea here is that you can already e.g. estimate RTT or even open the congestion window before you switch . There was already some discussion previously ( seePR ) if we want to have this in the document or say more or less . Maybe a question to the rest of the wg ( in the next meeting ) ... ? 
 Unsure about this in this ID : Is n't that suggesting a transport extension / mechanism update ... rather than the applicable use ? 
 I do n't think it needs an extension . It can simply be done by the client . It 's definitely not appropriate to specify a concrete algorithm in this document but it 's just listed as one of the things that padding can be used during mitigation . 
 I 'm really unsure about why text about priming is here and where the advice is located . I do n't dispute that it can be done , or even that if done appropriately it can help , however it could also be done in a way that might also hinder . If PR 122 removes this word , then this topic can be discussed elsewhere in RFCs . 
 PR was already merged a long time ago . I was just point at it to say that there has been previous discussion . As the label indicates , we plan to bring the for discussion to the meeting . 
 CC priming seems like an issue entirely internal to the QUIC implementation . Why should applications know or care about it ? I suggest we simply delete this . 
 I like suggestion . 
 is my proposal . It does n't talk about priming / pre - heating anymore but it says what 's possible and why this could be interesting for an application . 
 PR was merged . 
 We should probably make it clear what the application can do here ( SPA for servers ; maybe intentional migration for clients ? ) I 'm not sure if migration is transparent to client applications or not . 
 The client application might have some knowledge if it 's behind a NAT or not and as such might want to indicate to use Conn ID or not . We can make that more explicit in the text . 
 I did some small edits on the text in the connection migration section but maybe you had something more in mind and want to propose more text ? 
 This whole section should then also be moved to after the Conn ID section . 
 I like the move of text to the manageability draft . If it were me , I 'd move " Server - Generated Connection ID " as well , as I do n't think apps need to worry about it , but it 's not a big deal . I think adding text about server preferred address is probably more important for this draft . 
 Added some more text in 
 we think the current state of the draft addresses this issue ; could you check and close this issue if so ?
Paragraph (version A):
QUIC supports connection migration.  Even if lower-layer addresses
(usually the 4-tuple of IP addresses and ports) changes, QUIC packets
can still be associated with an existing connection based on the
Connection ID (see also section connid) in the QUIC header, if
present.  This supports cases where address information changes due
to e.g.  NAT rebinding or change of the local interface.  Currently
QUIC only supports failover cases.  Only one "path" can be used at a
time, and as soon as the new path is validated all traffic will be
switched over to the next path.  Of course if an endpoint decided to
not use the Connection ID in short packets (Zero-length Conn ID) for
a certain connection, migration is not supported for that direction
of the connection.
Paragraph (version B):
QUIC supports connection migration by the client.  If a lower-layer
address changes, a QUIC endpoint can still associate packets with an
existing connection based on the Connection ID (see also connid) in
the QUIC header, if present.  This supports cases where address
information changes, such as NAT rebinding, intentional change of the
local interface, or based on an indication in the handshake of the
server for a preferred address to be used.
Paragraph (version B):
Currently QUIC only supports failover cases.  Only one "path" can be
used at a time, and only when the new path is validated all traffic
can be switched over to that new path.  Path validation means that
the other endpoint in required to validate the new path before use in
order to avoid address spoofing attacks.  Path validation takes at
least one RTT and congestion control will also be reset on path
migration.  Therefore migration usually has a performance impact.
Paragraph (version B):
As long as the new path is not validated only probing packets can be
sent.  However, the probing packets can be used measure path
characteristics as input for the switching decision or the congestion
controller on the new path.
Paragraph (version A):
Note that the Connection ID in the short header may be omitted.  This
is a per-connection configuration option; if the Connection ID is not
present, then the peer omitting the connection ID will use the same
local address for the lifetime of the connection.
Paragraph (version B):
Note that the Connection ID in the short header may be omitted.  This
is a per-connection configuration option; if the Connection ID is not
present, then the peer omitting the connection ID needs to use the
same local address for the lifetime of the connection and connection
migration is not supported for that direction of the connection.