zilinlin/RFC2PSM huggingface dataset:
Section 1. Introduction

The Datagram Congestion Control Protocol (DCCP) is a transport
   protocol that implements bidirectional, unicast connections of
   congestion-controlled, unreliable datagrams.  Specifically, DCCP
   provides the following:
   o  Unreliable flows of datagrams.
   o  Reliable handshakes for connection setup and teardown.
   o  Reliable negotiation of options, including negotiation of a
      suitable congestion control mechanism.
   o  Mechanisms allowing servers to avoid holding state for
      unacknowledged connection attempts and already-finished
      connections.
   o  Congestion control incorporating Explicit Congestion Notification
      (ECN) [RFC3168] and the ECN Nonce [RFC3540].
   o  Acknowledgement mechanisms communicating packet loss and ECN
      information.  Acks are transmitted as reliably as the relevant
      congestion control mechanism requires, possibly completely
      reliably.
   o  Optional mechanisms that tell the sending application, with high
      reliability, which data packets reached the receiver, and whether
      those packets were ECN marked, corrupted, or dropped in the
      receive buffer.
   o  Path Maximum Transmission Unit (PMTU) discovery [RFC1191].
   o  A choice of modular congestion control mechanisms.  Two mechanisms
      are currently specified: TCP-like Congestion Control [RFC4341] and
      TCP-Friendly Rate Control (TFRC) [RFC4342].  DCCP is easily
      extensible to further forms of unicast congestion control.
   DCCP is intended for applications such as streaming media that can
   benefit from control over the tradeoffs between delay and reliable
   in-order delivery.  TCP is not well suited for these applications,
   since reliable in-order delivery and congestion control can cause
   arbitrarily long delays.  UDP avoids long delays, but UDP
   applications that implement congestion control must do so on their
   own.  DCCP provides built-in congestion control, including ECN
   support, for unreliable datagram flows, avoiding the arbitrary delays
   associated with TCP.  It also implements reliable connection setup,
   teardown, and feature negotiation.
Section 15. Forward Compatibility

Future versions of DCCP may add new options and features.  A few
   simple guidelines will let extended DCCPs interoperate with normal
   DCCPs.
   o  DCCP processors MUST NOT act punitively towards options and
      features they do not understand.  For example, DCCP processors
      MUST NOT reset the connection if some field marked Reserved in
      this specification is non-zero; if some unknown option is present;
      or if some feature negotiation option mentions an unknown feature.
      Instead, DCCP processors MUST ignore these events.  The Mandatory
      option is the single exception: if Mandatory precedes some unknown
      option or feature, the connection MUST be reset.
   o  DCCP processors MUST anticipate the possibility of unknown feature
      values, which might occur as part of a negotiation for a known
      feature.  For server-priority features, unknown values are handled
      as a matter of course: since the non-extended DCCP's priority list
      will not contain unknown values, the result of the negotiation
      cannot be an unknown value.  A DCCP MUST respond with an empty
      Confirm option if it is assigned an unacceptable value for some
      non-negotiable feature.
   o  Each DCCP extension SHOULD be controlled by some feature.  The
      default value of this feature SHOULD correspond to "extension not
      available".  If an extended DCCP wants to use the extension, it
      SHOULD attempt to change the feature's value using a Change L or
      Change R option.  Any non-extended DCCP will ignore the option,
      thus leaving the feature value at its default, "extension not
      available".
   Section 19 lists DCCP assigned numbers reserved for experimental and
   testing purposes.
Section 20. Thanks

Thanks to Jitendra Padhye for his help with early versions of this
   specification.
   Thanks to Junwen Lai and Arun Venkataramani, who, as interns at ICIR,
   built a prototype DCCP implementation.  In particular, Junwen Lai
   recommended that the old feature negotiation mechanism be scrapped
   and co-designed the current mechanism.  Arun Venkataramani's feedback
   improved Appendix A.
   We thank the staff and interns of ICIR and, formerly, ACIRI, the
   members of the End-to-End Research Group, and the members of the
   Transport Area Working Group for their feedback on DCCP.  We
   especially thank the DCCP expert reviewers Greg Minshall, Eric
   Rescorla, and Magnus Westerlund for detailed written comments and
   problem spotting, and Rob Austein and Steve Bellovin for verbal
   comments and written notes.  We also especially thank Aaron Falk, the
   working group chair during the development of this specification.
   We also thank those who provided comments and suggestions via the
   DCCP BOF, Working Group, and mailing lists, including Damon Lanphear,
   Patrick McManus, Colin Perkins, Sara Karlberg, Kevin Lai, Bernard
   Aboba, Youngsoo Choi, Pengfei Di, Dan Duchamp, Lars Eggert, Gorry
   Fairhurst, Derek Fawcus, David Timothy Fleeman, John Loughney,
   Ghyslain Pelletier, Hagen Paul Pfeifer, Tom Phelan, Stanislav
   Shalunov, Somsak Vanit-Anunchai, David Vos, Yufei Wang, and Michael
   Welzl.  In particular, Colin Perkins provided extensive, detailed
   feedback, Michael Welzl suggested the Data Checksum option, Gorry
   Fairhurst provided extensive feedback on various checksum issues, and
   Somsak Vanit-Anunchai, Jonathan Billington, and Tul Kongprakaiwoot's
   Colored Petri Net model [VBK05] discovered several problems with
   message exchange.