Use Cases and Requirements for QUIC as a Substrate
draft-kuehlewind-quic-substrate-02
Document | Type |
Replaced Internet-Draft
(individual)
Expired & archived
|
|
---|---|---|---|
Authors | Mirja Kühlewind , Zaheduzzaman Sarker , Thomas Fossati , Lucas Pardue | ||
Last updated | 2019-11-04 | ||
Replaced by | draft-kuehlewind-masque-quic-substrate | ||
RFC stream | (None) | ||
Intended RFC status | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | Replaced by draft-kuehlewind-masque-quic-substrate | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
TCP is often used as a proxying or tunneling protocol. QUIC is a new, emerging transport protocol and there is a similar expectation that it too will be used as a substrate once it is widely deployed. Using QUIC instead of TCP in existing scenarios will allow proxying and tunneling services to maintain the benefits of QUIC natively, without degrading the performance and security characteristics. QUIC also opens up new opportunities for these services to have lower latency and better multistreaming support. This document summarizes current and future usage scenarios to derive requirements for QUIC and to provide additional protocol considerations.
Authors
Mirja Kühlewind
Zaheduzzaman Sarker
Thomas Fossati
Lucas Pardue
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)