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

[Martin Duke <[e-mail]>]

Sowmini,

Hopefully draft-06 addresses your concerns.

Thanks again for reviewing

On Tue, Oct 29, 2019 at 2:04 PM Sowmini Varadhan <[e-mail]>
wrote:

> On (10/29/19 13:25), Martin Duke wrote:
> >    Hi Sowmini,
> >    Thanks for the review. I'll file a PR for your editorial changes.
>
> sounds good, thanks for doing this!
>
> >    0b11 is 2 bits. The '0b' notation indicates each digit is a bit; '0x'
> >    would be hexadecimal, where 2 characters = 1 Bytes.
>
> ah, this is the NIC data-sheet notation, that got me by surprise.
> If there is no strong objection, can we just list the code-points
> as "11" (I think this is the convention followed in other ietf rfcs,
> e.g., 3168, for the ECT code-points).
>
> >    In section 4, it says: " The load balancer SHOULD route Initial and
> 0-RTT
> >    packets from the client using an alternate algorithm". The point here
> is
> >    that the destination CID for these packets is chosen by the client.
> It may
> >    not be long enough to apply the chosen algorithm, so something else
> should
> >    be done. However, " This algorithm SHOULD generate consistent results
> for
> >    Initial and 0RTT packets that arrive with the same source and
> destination
> >    connection ID" so they all end up at the same place. If the LB
> doesn't do
> >    this, then the 0RTT packets will be lost. This is suboptimal but
> doesn't
> >    break the protocol.
>
> ok, perhaps it would be helpful to add some discussion around this
> in the draft.
>
> [discussion for "Section 4.3.1 refers to "token"]
> >    This is the QUIC-LB authentication token, which I should clarify. In
> any
> >    case, I don't believe that servers get this token if there's
> out-of-band
> >    configuration, so I need to fix this.
>
> Ok.
>
> [discussion around Section 5]
> >    This is for the benefit of the QUIC server. When the server gets an
> >    Initial Packet with a Retry token in it, it needs to extract the ODCID
> >    from that token so that it can send it back in a transport parameter.
> If
> >    the client got a Retry but then doesn't get the ODCID transport
> parameter,
> >    it means there's an unauthorized man in the middle and the client
> should
> >    terminate the connection.
>
> I see. In general, it would help to provide some context in this section
> about why any tweaks in the Retry Service are needed at all, along with
> your explanation above.
>
> Thanks!
>
> --Sowmini
>
>