Unreliable Datagram Extension to QUIC draft-pauly-quic-datagram-00 - - PowerPoint PPT Presentation

unreliable datagram extension to quic
SMART_READER_LITE
LIVE PREVIEW

Unreliable Datagram Extension to QUIC draft-pauly-quic-datagram-00 - - PowerPoint PPT Presentation

Unreliable Datagram Extension to QUIC draft-pauly-quic-datagram-00 Tommy Pauly , Eric Kinnear, David Schinazi QUIC IETF 103, November 2018, Bangkok 1 Why unreliable QUIC frames? Several application use cases take advantage of unreliable


slide-1
SLIDE 1

Unreliable Datagram Extension to QUIC


 draft-pauly-quic-datagram-00

Tommy Pauly, Eric Kinnear, David Schinazi QUIC IETF 103, November 2018, Bangkok

1

slide-2
SLIDE 2

Datagram Frame - QUIC - T. Pauly - IETF 103 2

Several application use cases take advantage of unreliable data QUIC can provide functionality beyond DTLS or direct UDP We have an extension mechanism in QUIC—let’s try using it!

Why unreliable QUIC frames?

slide-3
SLIDE 3

Datagram Frame - QUIC - T. Pauly - IETF 103 3

Share a single crypto handshake between reliable stream data and unreliable datagrams Inherit features of the QUIC crypto handshake that may not be present in DTLS (faster retransmission, transport parameters) Adds ability to acknowledge datagrams

Advantages over other protocols

slide-4
SLIDE 4

Datagram Frame - QUIC - T. Pauly - IETF 103 4

Applications that need to maintain both a reliable control stream and an unreliable frame flow Audio/Video Streaming, Gaming, etc. VPN-style tunneling of IP packets over a QUIC connection

Example use cases

QUIC Conn.

Unreliable datagrams Reliable streams

slide-5
SLIDE 5

Datagram Frame - QUIC - T. Pauly - IETF 103 5

DATAGRAM frame (0x1c - 0x1d)

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [Length (i)] ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Datagram Data (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length field is optional, determined by frame type. If absent, frame extends to end of packet. Adds an accepts_datagrams transport parameter to indicate support

Protocol details

slide-6
SLIDE 6

Datagram Frame - QUIC - T. Pauly - IETF 103 6

Should DATAGRAM frames be acked? Yes, as this adds more potential for sender to gauge loss on the network Acknowlegements do not guarantee that the peer application actually processed datagram

Design decisions

slide-7
SLIDE 7

Datagram Frame - QUIC - T. Pauly - IETF 103 7

Do DATAGRAM frames contribute to connection data limits? Current draft said yes, on the basis that it seems to violate the overall data limit otherwise List discussion highlighted that correctly interpreting flow control for datagrams adds too much complexity Any reasons not to remove this flow control?

Design decisions

slide-8
SLIDE 8

Datagram Frame - QUIC - T. Pauly - IETF 103 8

Can there be multiple flows (ID space) of DATAGRAM frames? No, as applications can add identifiers within frames themselves. IDs are more important for STREAM frames where there is per-stream flow control.

Design decisions

slide-9
SLIDE 9

Datagram Frame - QUIC - T. Pauly - IETF 103 9

Feedback welcome and encouraged! Not intended for initial QUIC version (don’t want to disrupt the schedule) Seems like a good test of extension mechanism for new frame types

Next steps

slide-10
SLIDE 10

Datagram Frame - QUIC - T. Pauly - IETF 103 10