Datagram Congestion Control Protocol WG (dccp)
Thursday, August 5, 2004 at 15:30 to 17:30
==============================================

The meeting was chaired by Aaron Falk.  Matt Zekauskas was scribe.

AGENDA
1. Agenda Bashing and Milestone Update
2. DCCP Spec
3. Changes to CCID 2 and CCID 3
4. CCID3-thin
5. DCCP Mobility and Multihoming
6. DCCP User Guide
7. Media Friendly Rate Control
8. Last Call Comments

=======================

1. Agenda Bashing and Milestone Update
   --Aaron Falk

   (see slides)
   - DCCP user guide is becoming more important

   - MFRC (Media Friendly Rate Control) is new

   - The specification, CCID2 and CCID3 are all under WGLC for
     Proposed Standard since 20-July.  The WGLC is scheduled to
     conclude 20-August.

   - Milestones were all just beyond last IETF; they've been adjusted
     to the next IETF, and most are now achievable.  There has been no
     input on the milestones.

  - On CCID and real time interactive traffic
      * We need measured data to support claims being made on the
        mailing list
      * TFRC for real-time flows discussion "most heated"

  - Comments about applicability need to be in the user guide.  There
    is a new revision out, please comment!  If you have concerns,
    sending text is always appreciated.

====================

2. DCCP specification, version -08
   -- Eddie Kohler

There were many little readability adjustments, which make diffs from
the last version look large.  However, there are two big technical
issues: Mobility and multihoming was removed, and the move to uniform
48 bit sequence numbers (versus 24).  The latter needs the most
review, please comment!

The sequence numbers used to be 24 or 48 bit, via negotiation.  Since
the recent TCP sequence number attack consciousness-raising, this has
been revised, since with 24 bits blind reset attacks are highly
probable.  Thus 48 bit sequence numbers are required for DCCP
requests, although 24 bits are allowed in three cases (data, datack,
and ack).

Mark Allman commented that 32 bits used to be OK for TCP too.  Eddie
responded that here "bits" means something different, you gain because
DCCP is per packet instead of per-byte; eventually you'll need a
timestamp.  Mark responded "or a challenge/response, or...".  Eddie
said that was true, but it's not necessary for the next "large number"
of years.

Colin Perkins asked why it was OK to protect against reset, but not OK
to protect against injection?  Eddie responded that the important case
is a half-open connection, because that's what made the blind attacks
bad previously.  We're trading off header size against the possibility
of attack, and feel that the application should make the decision.  It
is a working group question as to whether there are no applications
that would want to save 4 bytes of header.

Colin responded that he understands why it was done, but it makes him
uncomfortable, and applications might use the smaller sequence number
space without understanding the consequences.  Eddie said there was a
section in the draft on sequence number attacks -- and he'd love
advice on how to sharpen it: send text.  Colin felt that what was
there was good.

Mark agreed that what's in the current spec is about as good a
compromise as we can achieve.  Eddie amplified on his earlier
response: if you reset the connection, you're dead.  In the general
case insertion attacks generate results that are annoying, but not
fatal.  There is a difference in the magnitude of the attack on data
versus meta-state.  If an application really cares, set the option for
larger sequence numbers.  This seems to be a good compromise.

Allison Mankin said she wanted to echo what Eddie just said.  In his
review of the protocol, Steve Bellovin really downplayed the
significance of blind data attack.  There are few that make any
difference.  There is enough extensibility that an additional option
can be added to increase strength; it could even be proprietary.

Colin noted that DCCP was primarily for long-lived connections; he
understands but still isn't comfortable.  Eddie invited him to send
text.  Colin said he would re-read the text and forward any comments.

Eddie spent some time on feature negotiation (see slides).  A new
visible state was added ("unstable") to take care of a race condition.
However, the current document has some typos; this will be remedied
shortly.  Eddie noted that this might be reason to restart WGLC,
although he didn't think so.

Finally, Eddie mentioned a host of other small changes:

  * rearranged header... reserved above packet type so can have more
    packet types if needed.

    Eddie was uncomfortable with the extended seqno bit in
    middle.... and asked if there were any ideas on what else to do.

  * dccp sync: ack# not acknowledgment, because used to recover from
    confusion.

  * reset codes

  * options on reset are processed... you may reset a reset ...but
    there cannot be a storm.  Once a connection is killed, there are
    no more responses to reset.

  * min cksum coverage feature (willing to accept possibly corrupt
    data)

  * section on congestion state, and reset cong. state.
      mobility -> worth keeping?

Aaron Falk: taking bait... why not move X bit to end of byte so not
together.  Eddie said it was to keep type as a nibble, but no one
cares about that anymore.

Aaron asked for an example of an option in a dccp reset?  Eddie
responded it was there in case there was a reason in future for
conditionally resetting a connection.  He had some examples, but he
couldn't recall on the fly.

Aaron wondered if it was susceptible to 1/2 baked-ness of reset
congestion state.  If the path knows something, should it always send
that?  The effects of an option are carefully defined.  However, when
the option needs to be sent is undefined.

Aaron wondered if this was a general problem, although you may not
want to solve it here.  Eddie responded that it was possible that
there are cases when it is useful to tell the other side to reset
state & start again. But that is not without risk.  For example, in an
overloaded situation, 1 packet every 64 sec, this is like a "get out
of jail free" card.  That's a shame, but is also useful.

Tom Phelan: what do you mean by "if path changed".  Eddie said it was
from an email conversation, someone had example from mobility.  It's
in the draft, but he can't recall what it was... and said that we
should probably get rid of that option.  Tom agreed.

Magnus Westerlund said that because it's an option, we can add it
later, even if has applicability for future.

Sally Floyd agreed that it should be taken out of this, and put in a
separate draft, like mobility.

Aaron Falk said it's the right decision, it's gone.

======================

3. Changes to CCID 2 and CCID 3
   -- Sally Floyd

CCID2

  * description of response to idle and app-limited period.  In
    essence, just explain what TCP does.

  * Detecting lost and marked acks.  If a packet is lost, the receiver
    knows it (seqno missing) but doesn't know if ack or data (assuming
    2 way traffic).  The sender knows.  When the receiver sees a loss,
    it assumes ack loss for ack ratio.  There is an added appendix to
    show what this does...  worst case is the same number of data and
    non-data packets.  even in worst case, the cost is not that bad.

CCID3

  * added para on sending rate when no feedback (making it rfc3448
    compliant)

  * expanded discussion; packet size used in rate calculations

  * new section on response to idle and app-limited periods.

  * new text on data dropped and slow receiver (5.2) -- try to limit
    sending rate in next rtt (a bit)

  * new section outlining current research issues.

     - send fewer acks when rate low?  ok with me, but potential
       problem if a lot of acked packets

     - more than double sending rate from one RTT to next.  possible
       to relax, but...  again be careful

     - higher sending rate after idle period.  Should be more
       aggressive than after slow start, because been through slow
       start.  but how much more?

     - Initial send of 8 packets. TCP says 4 packets, at most 4k
       bytes.  It makes sense to send 8, but pace them out, and only
       if there is less than 4k sent.  However, Sally had "enough skin
       lost" getting 4 packet initial window, that someone should
       research this change.

Sally ended with a list of possible new efforts, for the groups
information:

  * re-invigorating quickstart

  * ccid for voip based on rfc3714 (because of IAB concerns about
    congestion control and voice traffic).  If encounter persistent
    congestion, must stop sending.  No numbers in the draft on how
    much over and how much to drop, just a principle statement.  ccid
    .. change minimum requirement to sufficient requirement.
    Something a little, but not much more, aggressive than CCID3

  * TFRC-PS, flows that adapt their packet size

===========================


4. DCCP CCID3-lite
   -- Eddie Kohler

This draft tries to demonstrate than although CCID3 looks heavyweight,
you can implement a CCID that is very streamlined.  This draft is
mostly updated based on changes to the main draft.  What is missing?
The loss-intervals option can't be turned on (hence no ECN).

Is this important enough work item for the group to accept, or should
it be put off until someone wants to implement DCCP on a really small
device?

Aaron Falk asked if anyone cares?  If not, he is going to kill it (as
a wg item).

Tom Phelan noted that what drove him to do this in the first place is
the thought of trying to sell DSP coders to implement DCCP on DSP.
The question now is if CCID3-thin is the right one to go on diet.
he's not sure right now, and think we ought to hold off until all the
congestion control issues settle.

Aaron gave the group a thought exercise: Have we learned enough from
complexity to answer the question?  Or is it useful for the WG to
prepare a standard that has a reduced specification?  These are two
different goals, one of which might not require an RFC.

Tom thought it depends on what want to do later, you can apply these
ideas to MFRC, and have a thin version of that.

Aaron said just call it a lightweight version of something.  Does it
require an RFC, or just a thought experiment?  Tom thought it had to
go to RFC eventually.  Aaron wanted to know if anyone else felt this
way.

Colin Perkins in a "devil's advocate" role, suggested that if there is
an interest in the draft, why not just implement DCCP simply.  DCCP
does not seem excessive, compared to ATM.  Aaron said that was a
different issue; Colin thought we should consider it, it did not seem
to be difficult.  Aaron noted that this is about a CCID, the rest is
modular.

Eddie reiterated that it was a CCID, not all of DCCP.  However,
this specification is also a combined simplification -- it restricts
what a DCCP implementation can do, and what the CCID can do. For
example,
  * no ack vectors
  * no renegotiation of options

Mark Handley said that to the extent that this is a profile for use,
and doesn't change specification, it is always useful to suggest
people a way to implement a useful subset of functionality.  He thinks
it is a useful informational draft.  As to whether main specification
might have too much in it, that's a question for all
protocols... people implement different subsets of features.  That's
why there are "bakeoffs".  Just because a stripped down version is
useful for lightweight devices, you don't want to cut out features
that are useful for devices that are not so lightweight.

Aaron noted that feature pruning is the kind of thing that happens
when a draft advances from Proposed Standard to Draft Standard.  Mark
said that you should do it then, but this is still a useful
informational draft.  Eddie notes that it is a bit of rewrite to make
it informational, because the draft allocates an option.  Aaron
wondered if anything in thin that violated a MUST in the
specification.  Eddie sad no, but it does allocate an option.

Colin wondered if a path forward is for the base specification to be
clearer about a minimal subset.  Eddie said there is an options table
that shows what is optional.  But 3-thin does more than that, it
constrains implementations.  This is so an implementation that only
spoke thin can speak to a full - the full implementation would not
generate a packet that violated thin rules.  This is different from
"optionally implemented" in a specification.

Aaron wondered if this violates "server wins"; if the client is thin
it supersedes server rules.  Eddie said no -- if a server doesn't
understand thin, by rules of mandatory, the server must reset.  The
server does win - it gets what it wants or no connection.

Tom Phelan said his drive was not that DCCP is too thick in general;
it was for streaming media devices that are very thin.  A protocol for
streaming media needs a thin variant, or needs to be very thin.

Allison asked for clarification of how thin relates to negotiation -
did it actually break the protocol?  Eddie said it does not break the
protocol.  It restricts the operation of an endpoint, but the endpoint
must agree to the restrictions.

Allison wondered why we were engineering something that could happen
naturally.  An endpoint could restrict itself anyway.  Eddie said that
all CCID3-thin packets are valid dccp packets.  But if you only
restrict yourself, you can't guarantee that a peer would do it.  Aaron
said that when one found something the other side didn't support, it
would just reset the connection.  Eddie said the point of 3-thin was
that the implementation didn't need to bother looking for strange
options; it's not to be a time-saver (although it does that) but it's
an implementation saver.  You just check at the beginning of a
connection.

Allison thought perhaps we're actually asking if we can create a kind
of extension to negotiation mechanism -- "negotiate out of rich
negotiation".  Asking to add vital small piece to proto that allows
that.  You need a part of the proposed standard to do that, why you
should do it now instead of later.  Eddie responded that this was not
quite true; you can go to proposed standard without this, since it can
go independently with some option number.  The "mandatory option"
concept is all you need in DCCP.  3-thin is in the header, as the
mandatory three-thin option.  There could be 3-thin, 3-thin2 or
3-thin3.  Don't need to pre-specify because we have the mandatory
piece.

Colin said he was still trying to understand the need.  Why not just
send "no" to all options?  Eddie because the implementation of a
3-thin client could be really simple.  Colin thought it just wasn't
that complex.

  Aaron asked for a hum of people that thought this was a reasonable
  activity to pursue.  Mild yes.

  He asked for a hum of people that thought this should not be
  pursued.  Mild no.

  There was a big don't care.

  Aaron said to take this off line... but there are not a lot of folks
  that support at the meeting.

=================

5. DCCP Mobility and Multihoming
   -- Eddie Kohler

This is a new draft, pulling material out of the main draft. (See
slides.)

Yet to be done: specify mobility secret format and encryption
algorithms.  The security considerations section.

The questions Eddie had for the group:

  * when we gave up on mobility in main spec, did we give up on it
    completely?

  * if no,
      - this draft
      - some other approach?

Magnus Westerlund said that considering what was said in TSVWG
today...  multihoming device could use different dccp sessions, and
use ICE to select.  Mobility might be better in a lower layer.  He
didn't know what was better, but felt that's what we need to look at.
Eddie responded that to be fair he wasn't at TSVWG, but he felt there
is a strong case to be made for supporting in transport layer (in
addition to, or instead of, the network layer).

Aaron said that he saw much of what would drive a decision here to be
things in other working groups. This is probably the wrong time to
make a decision.  You have put together a reasonable proposal.  His
suggestion would be to see what happens in other WG, and get rid of
other outstanding issues before revisiting this one.

Mark Handley thought we should keep going and see where it leads, but
don't make decision now if RFC.  Don't stop working on this since we
have a certain amount of stuff worked out.  He would like to get to
the point where it was all worked out... but ietf policy to see if
push forward into stds track.

Aaron asked for a show of hands people interested: 2 raised their
hand.  He said the onus is on those folks to take forward if that's
what they want to do.

Allison said that she sees a need for discussion.  Perhaps taking a
couple of days sometime, looking at what everyone has envisioned for
these services and solutions.  This would be to see what everyone has
discovered and learned, not "how to do them in X".  There are neat
things in this document.  Things learned and discovered are important
to the overall architecture, and people need to pool ideas.  She's
really happy this progress went on, and feels it could be an
experimental RFC.

Aaron said there are so many names for the issues on these
topics...  how would one characterize the topic for, e.g., an IAB
workshop?  Allison thought perhaps 'multiple addresses'.

Aaron summarized what he heard: encouragement for the work to be done.
It's not a WG item, but you can include the dccp list; collaboration
with people on the list is good and worth doing.

Allison said she would send a bibliography of pointers where to look
for mobility work on TSVWG list, in addition to the viewgraphs from
her talk at TSVWG.  She's not sure where the follow-up activity is
yet; suggestions on follow-up activities is also really important, and
please send those to the TSVWG list.

========================

6. The DCCP User Guide
   -- Tom Phelan

The changes for 01 were not substantive; diff marked versions pointed
to in draft.  (See slides.) The question is "what next".

Aaron asked who has read?  Approximately 7 people responded.  Rather
than flogging people for not reading it, prefer to get the existing
set of documents through WGLC, and then flog people.  He thinks this
is a very important document, applying DCCP to certain types of
flows. However, without more input it has a ways to go.  We need to
get group more involved.

Tom agreed to postpone work until after WGLC.

======================


7. Media Friendly Rate Control
   -- Tom Phelan

Tom started with background.  There were discussions on the mailing
list about TFRC versus interactive applications.  TFRC seems
reasonably good if not used for interactive traffic.  The MFRC draft
is a thought experiment of what you might want to do for interactive
applications, and to stimulate discussion.

Tom then went through the thought process he had leading to MFRC, and
the basics of MFRC (see slides).  Basically, let media applications
guess the rate, and react quickly if the guess is bad.

What are the next steps?  Based on mailing list comments:

  * restart is bigger problem than slow-start.  (agree, may add)

  * based on TFRC to make it simple.  but byte rate is better than
    packet rate for streaming media, and he'd like to investigate.

  * please help simulate
  
Tom asked where is the appropriate home for this work?  DCCP says, you
can't have congestion control work without a specification, but this
is easy to explore.  Eddie said that what the draft intends to say is
that CCIDs that are standardized will have IETF-approved congestion
control.  It doesn't mean you have to standardize cong ctl first.
However, DCCP is a congestion control protocol - can't have random
congestion control algorithms.

Aaron noted that the IANA rules for ccid in the draft is that there is
a requirement to first have a congestion control document before you
can get a CCID.

Mark Allman said he votes for "option 3": you need to simulate first,
see where the worst cases are.  This isn't baked yet.

Sally said that she agreed.  However, the home for CCID could be this
group.  Her assumption was that the place to bring it was this WG.

Ruediger Geib said that he worked on QOS for a large provider.  He
would transport applications using dccp, but use a different queue in
the router.  Then, TCP friendliness is not an issue -- only require
that DCCP flows were friendly toward themselves.  Because of separate
queues, it would be helpful to be able to get application to reduce
rate.  Another idea from TSVWG: use ECN.  Suggest you do
both... losses and ECN.

Tom said that loss or ECN marked is abbreviated by saying "loss".
Right now draft doesn't consider ECN marking.

Ruediger thought it would be nice to mention, not you personally do
work.  By the way, as a provider, we view losses as bad.

Aaron said that Mark is right.  There is research to be done.  Show
the results in AVT and here.  If there is a ccid to be defined, this
is the place, but that's the second step.  The first step is to figure
out the right thing to do.

Eddie said that a ccid draft is a useful way to work out details of
this as proposal.  So he wouldn't mind seeing more of this draft here.
Not that you shouldn't separate congestion control into a separate
draft.

Tom said that he wanted a ccid draft of this as one document, a
simulation study as another document, and to be able to continue to
talk about it here.

Aaron asked if anyone here wants to work on it.  No one raised hands.

========================

8. Last Call Comments
  -- all

Aaron wanted to follow up on a mailing list discussion as to whether
some or all of the drafts should go to experimental instead of
proposed.  The charter specifies that the documents go to proposed.
There are also issues people are raising between TFRC and real-time
multimedia traffic.  These are issues when trying to run this traffic
over specific CCIDs.  There is no applicability statement in any of
the documents in last call that require people to use a specific ccid.
DCCP is a piece of transport mechanism; we should standardize to get
people to implement it and use it.  More CCIDs would be developed with
experience.  Thus, he doesn't see a conflict with the fact that the
CCIDs may not be appropriate for streaming media, and taking the
existing documents to proposed standard.

  Colin agreed.  Get these documents out, and save the rest for later.

  Magnus thought he agreed in principle.  However, are the documents
  mature enough to go to proposed, without an implementation of the
  current spec?

  Aaron said RFC2026 does not require an implementation for proposed
  standard.

  Magnus thought it would be good to have an implementation to show it
  works.

  Aaron said that we know the requirements; there are early
  implementations, we've been talking about it for two years, and
  there's been a detailed design review.  No one is raising new issues
  with the main specification mechanism.  If someone can put issue on
  table, let's discuss.  Free-floating anxiety is hard to work on.

Magnus noted there was a new state in this version.  Aaron wanted to
know about new mechanisms.  Eddie agreed about the new state
(UNSTABLE), but it's for feature negotiation.  There is an existing
state machine there.  Previously there were STABLE and CHANGING.  Now
there are three.  However, this is not the main DCCP state machine.

  Magnus said that we haven't had one round that deals only with
  editorial comments.

  Steve Casner echoed Magnus's comments.  He doesn't dispute Aaron's
  position, but there are certain things that he's not quite certain
  about.  It seems a little less than ready for last call and send it
  on.

Unidentified from Orange, works on 3G phone issues.  He had an
interesting conversation with Sally.  How well does DCCP apply to a
wireless link?  Some transport protocols cause lots of problems.  Not
congestion - but strange behavior on radio side causes false alarms.
Would dccp behave better in a strange or variable radio condition?

  Eddie asked for clarification: do you mean "if tcp behaves badly in
  highly variable link, will dccp also?"

  ???: Actually, if delay spikes.  We see huge delay spikes on radio
  links.  It will cause TCP to slow down, and tremendous HTTP
  problems.  Packets are not lost, but buffered in the radio link.  It
  produces a shot of high delay in short period of time.

  Mark Handley said that what would probably happen is that a decent
  CCID 3 implementation would carry on transmitting through delay.  It
  may tell the sender to back off rate, but when get feedback, it
  would go ahead.  So the answer is "yes, it should be better than
  TCP"

  Eddie wasn't sure, because he wasn't sure of the application.  If
  you want reliable byte stream delivery, then it's a congestion
  control concern.  You probably need CCID4/MFRC

  Aaron said that if you use CCID2 with data, you should have a big
  win over TCP if there was a delay spike.

  Sally said we should take this issue to the list.

Colin Perkins said that he was not worried about applicability to
particular applications, since we can develop new CCIDs if we need to.
He's worried that we are trying to push something to proposed when
it's not yet stable.  9 pages of significant revisions in this version
of specification, plus the CCIDs. He thinks it is a good piece of
work, and shaping up nicely, but is not convinced it's stable.  He's
worried that we set it in stone too early - don't force it out.

  Sally responded that we can't expect long term stability before PS,
  look at what is happening with TCP; it's not stable.  We are trying
  to do HS-TCP because the current TCP doesn't work in a large
  congestion window environment.  Then there's the big tussle over the
  reset attack.  The work within TCPM is robust to reordering, and it
  should have been done day one.  TCP is not stable.  If we want to
  wait for the specification to be completely stable, then it will
  never happen.  Holding a bigger bar to DCCP and TFRC than TCP
  doesn't make sense.  All changes Sally presented were text- no new
  mechanism.

  Eddie added another point: there were technical changes made to main
  specification.  However, they were all sent to the list, and
  received no replies. He will release another draft once he's done a
  full read through.  Not sure if this would address stability
  concerns of Magnus and Colin.  The authors are now talking only to
  themselves.  The draft will get stable in your perception that way.
  We need to get others to read whole document again.  The last person
  to read the whole document was Magnus...  if no one is going to do
  it again, what are we waiting for?

  Mark Handley added that he wouldn't object to delay if something
  would happen.  More reviews, for example...

Aaron asked who has read this version of specification: about 5 hands.
He then asked who would commit to reading this version of the
specification; another 10 raised their hands.

  Aaron said that he expects to see typos posted to list.  If you
  can't find an error, he'll assume you haven't read.  There's another
  two weeks after the IETF in the last call.  He'll ask for more on
  the list if we need it.

  Colin thought this was unfair: people have been giving comments at
  every IETF, and there have been significant changes before each
  IETF.  Aaron asked if there had to be one IETF meeting with no
  significant comments.  Colin said the spec must be out there long
  enough to read and digest.

  Aaron said that the authors think the drafts are stable, and it is
  time for the community to look and see if it's stable.  We can do
  that now, there is no need to wait four months.

  Eddie said that the current specification has a typo or two (see his
  presentation).  He agrees that there have been technical changes in
  the last revision, but they were circulated to the list.  He would
  not feel "bashed on" to be asked to come up with new revision of the
  main specification for last call.  However, he also thinks that a
  last call on the current specification is OK.

Randall Stewart said that he had the same opinion as Sally, having
gone through the SCTP specification.  You're going to make mistakes.
The only way you're going to find them is by getting people to
implement the specification.  There will be other problems.  he
doesn't see any harm in going to proposed; you may have to cycle at
proposed again based on changes.  That's OK.  In the end the document
will be much better.

Allison talked about the IESG's interpretation of proposed standard:

  * no known flaws (so fix the bug)

  * WGLC is on a document that had changes.  We're now looking at the
    document since changes made.

  * There's no need to restart the LC, since the changes are in
    response to discussion.  They see a lot of that - the document can
    go through big changes during WGLC; what's happening now is the
    response.  She thinks it is appropriate.

  * Sometimes after IETF last call, the document gets a large change.
    They accept that.

  * There's no need to be overly conservative for proposed; we don't
    require deployment, but do require people think that the spec can
    be implemented.

Her feeling is that it is time for IETF LC on this, and would
encourage closure.

Mark Allman said that he too agreed with sally; its not going to be
perfect, it's never going to be perfect.  The document will change
(maybe big things) as an RFC.  It's time to get a stable version that
people can start implementing.

Aaron ended the meeting with a charge to the WG to go forth and read
the documents in last call.
</xmp>