tfpauly/draft-pauly-quic-datagram

Issues

• Specify Max Payload Size instead of Max Frame Size

  #30 opened 5 years ago by nibanks
  3

• Consider retransmission bit leakage

  #32 opened 5 years ago by chris-wood
  2

• remind implementors of the "fun" parts of no flow control

  #33 opened 5 years ago by grmocg
  1

• Draft 05 defines how many frame types?

  #29 opened 5 years ago by LPardue
  1

• Small max_datagram_frame_size that peer cannot send DATAGRAM frame

  #15 opened 5 years ago by flano-yuki
  0

• Clarify lost datagram

  #16 opened 5 years ago by mikkelfj
  3

• Explain how max datagram frame size interacts with PTMU

  #2 opened 5 years ago by tfpauly
  3

• API considerations for lack of DATAGRAM support

  #13 opened 5 years ago by rpaulo
  2

• 0-RTT clarifications

  #14 opened 5 years ago by rpaulo
  1

• Make discussion of flow identifiers more vague

  #18 opened 5 years ago by DavidSchinazi
  0

• Specify whether empty DATAGRAM frame are allowed

  #19 opened 5 years ago by DavidSchinazi
  8

• Should DATAGRAM frames include some sort of ID field

  #8 opened 5 years ago by erickinnear
  8

• Receiver SHOULD ACK before dropping datagram frames

  #12 opened 5 years ago by goelvidhi
  2

• Datagram flow prioritization

  #10 opened 5 years ago by tfpauly
  1

• Flow control for datagram flows

  #7 opened 5 years ago by goelvidhi
  7

• Congestion control

  #5 opened 5 years ago by DavidSchinazi
  6

• Should we call DATAGRAM ID -> DATAGRAM FLOW ID?

  #3 opened 5 years ago by tfpauly
  5

• Section 5 Nit

  #4 opened 6 years ago by tfpauly
  0