Re: [dccp] What's in the new drafts?

[Eddie Kohler <kohler@icir.org>]

In addition, I think it's worth saying that this author, at least, believes
that DCCP is essentially done, modulo rewriting for clarity and ease of
understanding.  The expert reviews were great, and we've addressed the
issues they brought up.  Most of the issues remaining, such as how CCIDs
can handle applications that change their packet sizes, are research issues
for which we have good interim solutions; they should not hold up the
protocol further.

My highest-priority issues remaining:
* # NDP -- keep it? drop it? reduce it to 1 bit?
* How to deal with Data Dropped requirements, such as "reduce send rate by
  1 packet per RTT", in TFRC?
* ECN-Capable should fall back to non-ECN-Capable if the first ECN-Capable
  packet is dropped (probably by a middlebox)
* Remove Identification and Challenge?
* Rewrites for clarity:
  - Produce a written-out algorithm for packet processing, like pages 52-78
    of the TCP RFC (clarity)
  - Text figure for state diagram (clarity)

Issues brought up at the review where I like the solutions we have:
* Partial checksums
* Data Dropped
* Mobility (I think now that we should keep it; Lixia Zhang's argument,
  that DCCP is a next generation transport protocol, so keep mobility and
  do it right, was a powerful one)
* Complexity (CCID 3-Thin)
* Checksum type (Internet vs. HMAC/UMAC/whatever) -- I think Internet
  checksum is far better understood, and easy to update incrementally,
  making it the right default; and the benefits of HMAC/UMAC/whatever
  may be achievable through special checksum options
* Sequence number security

Issues that may require research and should not hold up the protocol:
* The "DCCP, TFRC, and VoIP" issues described in mail earlier this week

Eddie

_______________________________________________
dccp IETF mailing list: dccp@ietf.org
list info:  https://www1.ietf.org/mailman/listinfo/dccp
wg charter: http://www.ietf.org/html.charters/dccp-charter.html