draft-duke-quic-load-balancers-05.txt

[Sowmini Varadhan <[e-mail]>]

Hi Martin, Nick, 

I read through
  https://www.ietf.org/id/draft-duke-quic-load-balancers-05.txt
and had a few comments and questions..

- (Editorial) s/encoding/encode at line 306 in Section 2.4
 302 2.4.  Load Balancer Chains
 303 
 304    While it is possible to construct a scheme that supports multiple
 305    low-state load balancers in the path, by using different parts of the
 306    connection ID to encoding routing information for each load balancer,
  :

- Section 3.2: Config rotation is one octet (per Section 3.3) and 
  there are 2 bits for config rotation, so it is confusing when Section 3.2
  says
 361    received these, it MUST generate connection IDs with the config
 362    rotation bits set to '0b11' and MUST use the "disable_migration"
  (0b11 is 2 bytes? In general, it would help to provide more context about
  what/when/how this can happen, and why it is needed)

- Section 4 ("Routing Algorithms"). The 0-RTT can have application data.
  Given that Section 4 discusses an "alternate algorithm" for 0-RTT,
  is it possible that the data from 0-RTT gets routed differently than
  the remainder of the packet? 

- (Editorial) The third paragraph in Section 4.1.2 referes to a "figure
  below" that seems to be missing? I am referring to the lines below:
 457 4.1.2.  Server Actions
  :
 468    The figure below clarifies the format.  The first two bits are
 469    reserved for config rotation.  The server can assign the next 6 bit
  :

- General editorial comment: missing a defintions section for acronyms
  like SCID and token. I realize that the Normative reference here is
  [QUIC-TRANSPORT] but it may be helpful to include a cheat-sheet of the
  main concepts like Initial, 0-RTT, Retry, SCID, Token (to name a few)

- Section 4.3.1 refers to "token". Is this the token from the Initial?
  From the Retry? The LB is just a service in the middle, between the
  2 quic endpoints, so it would help to explain which token to use. 
  To be clear, I am referring to:
 604    The load balancer decrypts the server ID using 128-bit AES Electronic
 605    Codebook (ECB) mode, much like QUIC header protection.  The nonce
 606    octets are padded to 16 octets using the as many of the first octets
 607    of the token as necessary.  AES-ECB encrypts this nonce using its key
 608    to generate a mask which it applies to the encrypted server id.


- Editorial: s/decrypts/encrypts in second paragraph of Section 4.3.2:
 631 4.3.2.  Server Actions
  :
 640    The server decrypts the server ID using 128-bit AES Electronic
 641    Codebook (ECB) mode, much like QUIC header protection.  The nonce

- Section 5: this one was particularly hard for me to read. I think it 
  would help if this section of the draft hsd a top-level discussion on 
  why this is needed (i.e., what are the sort of things that can go
  wrong if it is not there? Also, in Figure 5, why do we need to encode
  ODCIL and ODCID in the Retry token, given that they are already there
  in the Retry packet itself?)

--Sowmini