[dccp] design review comments from Rob Austein

[Aaron Falk <falk@isi.edu>]

----- Forwarded message from Rob Austein <sra@hactrn.net> -----

Date: Fri, 08 Aug 2003 17:01:32 -0400
From: Rob Austein <sra@hactrn.net>
To: Aaron Falk <falk@ISI.EDU>
Cc: Allison Mankin <mankin@psg.com>
Subject: Re: request for written reviews for DCCP

At Thu, 17 Jul 2003 00:45:40 -0700, Aaron Falk wrote:
> 
> I'd like to include a written review from each of you in the meeting
> minutes.  Please send what you can before the end of next week (July
> 25th).  (Steve-  I have your notes from the meeting.  Just let me know
> if I should expect anything else.)

Past your deadline, but perhaps better late than not at all.  The
following is based on a combination of what the minutes claim I said
and what I had written down prior to and during the meeting.

- Overall, I like this protocol a lot.  I was scared initially by the
  size of the spec, but upon reading it I concluded that it's dealing
  with issues that it has to deal with -- in spite of the differences
  from TCP, it has to deal with many of the same issues.

- DCCP service names look like a compromise between well-known ports
  and "contact names" as used in protocols like Chaosnet.  Personally,
  I'm a big fan of contact names, so if DCCP wants to stay away from
  well-known ports, I'd recommend moving in the direction of contact
  names.  However, given some of the issues raised at the meeting
  regarding feature creep, NAT traversal, and so forth, it might be
  better just to revert back to well-known port numbers (sigh).

- Sequence number field seems too small, even granting that it's
  counting packets rather than octets.  One possible way of fixing
  this would be to identify a few fields in the packet header that
  could reasonably be turned into options instead, then rearrange to
  widen sequence numbers to 32 bits.  CCVAL and NDP look (to me) like
  candidates for fields that could be turned into options.

- In reading the spec, my overall impression was that the balance of
  SHOULDs to MUSTs was weighted a bit heavily towards SHOULDs.  While
  I undestand the desire not to forbid anything that's not obviously
  going to cause harm, the flip side of that is a desire to avoid
  unnecessary complexity.   Excessive use of SHOULD instead of MUST
  tends to result in implementations that have to test for a lot of
  conditions and handle all possible cases.

- "Californian feature negotiation" ("Please do A", "I'd rather do B",
  "Please do A", "I'd rather do B", "This isn't working, goodbye").
  My impression of the negotiation mechanism was that it was prone to
  looping, which the designers clearly realized since they added an
  explicit loop-breaking mechanism.  I'm more comfortable with
  mechanisms like TELNET's option negotiation in which one party
  approaches the other on bended knee and no looping is possible.

  Since the Vienna meeting I've received mail describing a change to
  the feature negotiation mechanism.  I haven't gone over this with a
  fine tooth comb, but on a quick read it does seem to be heading in
  the direction I was suggesting.

- The "slow receiver" mechanism is a good idea, but I think that it
  needs to convey more explicit information to the sender, since
  otherwise the sender is left guessing as to what the receiver wants
  it to do.  Entirely too much of TCP is based on one party guessing
  about the other party's state, I'd rather avoid repeating that mess
  in DCCP at least in cases where an explicit mechanism is easy to
  provide.  See, eg, the discussion of the sender -increasing- its
  sending rate in response to receiving a slow receiver option: while
  this might be a reasonable thing to do, I'd be a lot more
  comfortable with doing it because the receiver said to do so.

- I really like having the ability to put data in the connection
  request (that's another thing I miss from Chaosnet).  As currently
  written, however, there are so many caveats about how this is
  handled that it doesn't look like an application can ever rely on it
  for anything.  I recommend fixing that to make the mechanism useful.

- There are a lot of places in the document where the motivation for
  doing things in a particular way isn't obvious.  I strongly suspect
  that there is a rationale in all (or at least most) of these cases,
  but it's hard to figure out from the raw spec.  Dunno whether it'd
  be better to address this via inline explanation or a companion
  document, that's partly just a matter of style.

- I'm not convinced that the mobility stuff is the potential
  complexity of making it work (eg, in the presence of NAPTs).

- It might be useful to have an optional text error message in
  addition to the numeric error codes.

- 16-bit ones complement sum isn't wonderful, but it's well-understood
  and we know how to update it incrementally, which might matter if
  one expects this protocol to be able to traverse NATs.

- At the time of the Vienna meeting, I was pretty sure that the
  partial checksum stuff wasn't worth the trouble.  I'm still not
  convinced that it's a good idea, but subsequent discussion (at and
  after the IAB plenary) helped me to understand the issues better.
  I agree that, -if- one is to support partial checksums, it needs to
  be done here, and this is a reasonable way of doing it.  The open
  question is a more fundamental one of whether we should support
  partial checksums at all, and the verdict on that is still out.

  Speculating wildly, one possible outcome of this debate could be
  something like a pronouncement that partial checksums should only be
  used in applications whose specification explictly states that doing
  so is ok.  But even that has interesting interactions with, eg,
  IPsec (the juxtaposition of the wiretapping and partial checksum
  discussions at the IAB plenary was particularly ironic).

----- End forwarded message -----

_______________________________________________
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