Subject: [QUIC] QUIC, what features we need?

From: Saku Ytti <[email-masked]>
Date: Wed, 20 Jul 2016 18:58:05 +0300

I really like QUIC, I think new L4 is key to great many advantages

- It separates location (IP) and ID (encryption signature), allowing
'mosh' like mobility for all applications
- it gives us 0 RTT UDP like behaviour, without amplification potential
- it does packet pacing, removing need for expensive large packet
buffers in the network
- FEC seems like great idea, why is it being dropped? Too complex?

MinimaLT has at least one feature QUIC does not have, it can present
client a puzzle, before servicing client. Would this be useful in
mitigating DDoS attacks? Could middlebox present the puzzles?

Should/could QUIC provide VPN like behaviour? Imagine my employer
gives me public key to sign my QUIC packets with. This signature is
verified by my employers border router at wire-rate, it cannot decrypt
anything, but it could verify the signature. If signature is OK,
border router allows QUIC packet, otherwise it does not.
Now in my linux box I could do something like ip route add
91.198.120.0/24 192.0.2.42 quic-sign XYZ. Or perhaps I'll do quic-sign
policy based on process name. Of course protocol does not care how the
signature ended up there, but I wanted to share what kind of
possibilities it would open.

If such signature capability would be added. Should it be deployable
by NPU's shipping now or shipping soon? Some NPUs will support MacSec,
could same hardware verify QUIC signature?

-- 
  ++ytti

---

From: Ian Swett <[email-masked]>
Date: Wed, 20 Jul 2016 12:02:13 -0400

> - FEC seems like great idea, why is it being dropped? Too complex?

FEC is not being dropped permanently, only the original incarnation of FEC
in QUIC, which only supported recovery of a single packet via XOR.

See the FEC v1 summary for more details:
https://docs.google.com/document/d/1Hg1SaLEl6T4rEU9j-isovCo8VEjjnuCPTcLNJewj7Nk/edit

> _______________________________________________
> QUIC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/quic
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 20 Jul 2016 18:15:26 +0200

Just to provide one more detail ...

> in QUIC, which only supported recovery of a single packet via XOR.

One of the biggest reasons I sponsored the QUIC BOF was that the proposed
charter includes an extension mechanism, so that extensions like FEC can be
developed without bumping the QUIC version number.

Once the extension mechanism is defined, things get easier.

Spencer