Datagram Congestion Control Protocol WG (dccp)
Monday, November 10 at 1530-1730
================================
CHAIR: Aaron Falk
Minutes taken by: Gorry Fairhurst
Slides at: www.icir.org/kohler/dccp/ietf58
Note from Agenda:
As we are planning to have a working group last call (WGLC) after
IETF-58 for the spec, CCID-2, and CCID-3, this meeting is the time to
raise any showstoppers. We'll spend most of the meeting discussing
changes that occurred to the spec as a result of the reviews we held
over the summer.
AGENDA
Agenda bashing,, schedule, discussion, etc 10 min
Design Review Followup 60 min
Open issues
Changes made
No change needed
CCID-3 Thin discussion 15 min
User Guide 15 min
==============================================================
0. Agenda bashing
-------------------------------
1. WG management stuff
CHAIR'S COMMENTS
Most of the activity in the working group since the IETF-57 (in
Vienna) has been focused on addressing issues raised in the review
process which included expert reviews and a design review
presentation in Vienna. The current priorities for the working group
are
a) get the spec and CCIDs to working group last call (wglc), and
b) start in earnest on the User Guide.
The current revision of the spec (-05) incorporates a lot of new text
and may design changes as a result of review comments. These
changes have generated additional comments and review. So, it is
unlikely that the next rev will be ready for wglc. Nor is it likely
that the document will be settled in November, as our current
milestones state. Additionally, the User Guide has not been revised
since October 2002.
Therefore, the schedule for the working needs to change. (The issue
of the User Guide will be addressed later.) The current milestones
(agreed to at the Vienna meeting) are:
CURRENT SCHEDULE
Sep-Nov 03 Incorporate review and implementation feedback into
spec
Oct 03 Collaborate with avt wg on API
IETF-58 Prepare for WGLC
Nov 03 WGLC for spec, CCIDs
Dec 03 WGLC on User Guide
The new proposed (& more detailed) schedule pushes wglc out another
month (ambitious but possible), adds some additional revisions in,
and gives a plan for the User Guide.
PROPOSED SCHEDULE
IETF-58 Collaborate with avt wg on API
IETF-58 Prepare for WGLC
Nov 03 Revise spec, CCIDs
Dec 03 WGLC for spec, CCIDs
Dec 03 Publish user-guide rev1
Feb 04 Publish user-guide rev2
Mar 04 WGLC on User Guide
This will be sent to Allison, our Area Director, for approval and
posting on the charter web page. It's important to keep in mind
that the priority is producing a quality spec and, therefore, the
schedule may slip out if additional time is needed to get adequate
review or resolve new issues. Nevertheless, WGLC is an important
milestone and has the added benefit of encouraging broad and serious
review. So, we're going to stick with this plan for the time being
and make coarse corrections as necessary.
Discussion:
Mark Handley (MH): Wednesday AVT WG meeting will talk about the API, do
attend.
Colin Perkins (CO): This seems time scale seems remarkably tight.
AF: We have everything on the table.
CP: Have you allowed sufficient time for ideas to percolate? Is one
week sufficient time to let people comment?
MH: There are some fairly significant wording changes needed - which
will be out in a week's time. This second one week review period
is about the clarity of the document. - Adding extra time
doesn't create extra reviewers! This schedule may be OK.
AF: Do you want to suggest a change to the schedule?
CP: If you can get a handle on this, its OK.
------------------------------------------------------------------------
--------------------
2. Open issues that need to be resolved before WG Last Call (by Eddie
Kohler (EK))
Datagram Congestion Control Protocol Specification
http://www1.ietf.org/internet-drafts/draft-ietf-dccp-spec-05.txt
Feature negotiation - used to be "California style", now negotiations
have been stream-lined into one exchange. No simultaneous negotiation.
Extended sequence numbers. DCCP-Sync to reduce cost of attack.
Discussion:
CP: Thinking about the recovery from loss - Is this a case where you
have to wait for a round trip time? And so, what do you do with
the data that is sent?
EK: The reason for the sync is because you saw a lot of loss, so yes
this loss will continue during the re-sync.
CP: Do you have to buffer data while a DCCP Sync is sent?
EK: You don't have to buffer at the receiver after a Sync. The
packets may, or may not, be accepted.
CP: Looking at the figure on the slide, DCCP-A (right) receives data
with a bad sequence number, and then...
EK: This is dropped.
CP: That's fine.
MH: This data must be dropped to ensure DoS prevention, but an
implementation could decide to keep it, and use it later.
EK: That's not in the Spec.
CP: If everything is working, you *may* want to buffer it, and then
later use it.
"Mandatory option" added.
EK: This is a strange term!
Greg White: Is it better to call this a "required option"?
EK continued to review Open Issues:
- Moved many SHOULDs to MUSTS
- More info on DCCP-Reset and Ignored
- CCID-specific Reset Reasons
- removed language saying DCCP spec would automatically follow TCP
& TFRC
Open Issues
# Non-Data-Packets, NDP
EK: keep it? drop it? reduce it to 1 bit? The goal is to make DCCP
sequence numbers useful to applications. However, there are
problems with ambiguity and interest by apps. Recommendation is
to make NDP a feature.
EK: Does anyone want to use the NDP value?
Magnus Westerlund (MW): Most applications implement a sequence
number, why can't we allow this in DCCP providing it for future
applications builders?
EK: We can , but it's not necessarily what they want. The required
framing is not so clear, applications may send multiple chunks
and want to number each of them, some chunks may be more/less
important. It's a good argument to have the feature, but its not
clear all applications will use it.
MH: A new application might like to have the sequence numbers
present. For RTP, this is a non-issue, it uses it own numbering
space. For other generic applications, this could be good. The
argument is good for making it available. It would seem for
applications that it would be better to have a segment number
space for only data packets, but this hard for DCCP the way it
is designed. The current proposal seems to be as close as
optimal for applications.
CP: An application may want to use the DCCP sequence number, because
it cares about the number of bits in its own headers.
EK: The advantage of the NDP option is it is not required for most
data packets - it occurs on non data packets themselves, plus
one following data packet after a burst of non-data packet(s).
MH: This moves the sequence number space out of the DCCP base header
and in to the non data packet header.
CP: This is probably Ok, but it needs thought.
EK: This came about, from stealing one bit for the X field and lead
to questioning the usefulness of the remaining 3 bits ad a NDP
count.
CP: Yes - 3 bits is not much use for this, so we should do something
else.
Connection identification nonces
Replaced by sync and new mobility ID. Need to look at the security
issues of move and check this is OK. There's a potential attack
where an application grows a large window using small packets, and
then switches to large packets. In fact, simulation shows this may
not be as beneficial to the application as it may seem.
Data Dropped & TFRC and CCID-3
Signals "I dropped this packet because my receive buffer is full,"
Sender should slow down. There's an open question of how to do in
TFRC? Author's recommendation: recommend a decrease in rate to
sender.
Packet Sizes
CCID specified in packets, not bytes. But applications determine
how long packets are. An app may build up a large window by sending
small packets then changing to large packets. Author's
recommendation: Observe that packet size attacks don't win in the
long run. Plan to remove packet size limit but add text that
implementations check for packet size gaming.
Payload Checksum and link CRCs
To be discussed with Gorry Fairhurst and others, but not a core
issue. I think we know what we need to decide, but first is it useful?
Tom Phelan (TP): Payload checksum option: Applications would usually
choose the partial coverage, because they really want to just do
their own action on the payload. A check other than the 1s
complement is good, that is, one stronger than the Internet
check would be better.
EK: An application may want to receive a packet that's got a good
header, but also know whether the payload is good or
bad. Application can use this data (and utilize the signal -if
it wishes). The congestion control procedure can also know the
data got there, and avoid the "cost" of a loss event, even if
there was a payload error.
MH: The payload coverage decouples the congestion control from the
application response. The rationale of choosing the Internet
checksum for the DCCP header (main checksum) isn't the same case
for the payload checksum. A different checksum (e.g. following
SCTP, is quite possible).
TP: A stronger checksum is better for this.
Stuart Bryant: If we use DCCP for PWE with partial coverage and want
to implement this for the switch fabric, the hardware can only
see the first few bytes of each packet and really would not want
to have the cost of the payload coverage checksum.
EK: It's an option only, you don't need to use the Payload Checksum
option - it's an *optional* option.
Voice over IP Issues
Dave Oran (DO): So the title of the slide says VoIP, rather than
multimedia. VoIP only exchanges very small chunks of data. For
VoIP, i can choose to double the packet sending rate (in bytes
per second), by simply using bigger packets.
SF: TFRC is specified for a source with packets of only the same
size. A new spec would be required to specify fixed sending
rate and variable packet size.
DO: So, it's not really VoIP? - the choice of 120B v 240B VoIP
payload is an easy choice for a VoIP codec. Counting packets to
control a low bandwidth application is weird?
EK: This is for lots of applications - not just VoIP.
TP: Changing the packetisation rates also reduces the average packet
rate. Increasing the packetisation rate also reduces the bytes
per second for the same codec (since there are less overhead
bytes/sec).
------------------------------------------------------------------------
--------------------
3. Review of fixes for problems that were identified in design review
(by EK)
Partial checksums
EK: Should the checksum coverage unit by 8 byte or 32 bit chunks?
CP: 8 bytes is really bad. Considering the AMR codec format for RTP
(the main use), 8 bytes is too much!
EK: Is 56 bytes enough?
CP: I think so, I will check.
Q: For video codecs it *may* need more!
EK: Why? How much?
Q: Don't know!
EK: Can anyone who has *any* views or knowledge, please tell the list?
Checksum type (Internet vs. HMAC/UMAC/whatever)
ID authors believe internet checksum is good. Data Dropped - ID
authors say the data is received. Is endpoint congestion, still
congestion? - ID authors do not believe so.
- Data Dropped
(original comment from Greg Minshall) Semantics of packet receipt
should be different. Do you ack when packet goes into receive buffer
or to app? Authors disagree: endpoint drops should not be treated
as congestion. May mention possibility of treating buffer loss as
congestion in draft.
MH: if you do, don't mess up congestion control calculations for RTT.
Mobility
ID authors wish to keep this.
Sequence number security
Looked at, and kept.
DCCP CCID-3 Thin
http://www1.ietf.org/internet-drafts/draft-ietf-dccp-ccid3-thin-00.txt
A simple DCCP with TFRC designed for lightweight implementation
processing, all features are fixed, ACKs are fixed format. Should
we allow ECN (and NONCE verification)?
Mike Luby (ML): What is the target device? Why would someone use
this instead of the full spec?
EK: Simple devices that do not want to do a full implementation or
use an implementation where this is hard. e.g. Mobile devices.
ML: So you took out mobility? Which is what small mobile devices
probably need!
MH: A disadvantage is that to do this, all DCCP servers would need
to support this, This requires alternate code implementations to
support the 3-thin profile.
EK: That is fair. However, it's not as hard as making a new CCID!
MH: Should we review all the things that will need code-path
changes? - These may need much more thought, and if we do this
we could make the design simpler.
------------------------------------------------------------------------
--------------------
4. CCID-3 Thin discussion, hum on making it a wg product..
AF: Should this be a WG item?
EK: We should take this on - we heard comments from people who
feared complexity. This would be a simple mechanism for devices
that do not wish to use other CCIDs
TP: I was finding it hard to get people to implement this in DSP
chips! We need this so that it could be used!
AF: What are the devices? - Mobile?
TP: Large voice devices that have to handle lots of connections.
AF: Who would like to implement this?
Response: few (2)
AF: Who would like to do any CCID?
Response: few (2)
AF: Who should take this on as a WG item?
Response: lots (24)
AF: Who not?
Response: few (2.5)
MH: Even if this is a WG item, we can evaluate this later if it is a
bad idea.
AF: But I'd like to see this WG wound up soon!
AF: Eddie you mentioned several issues that may require further IDs
in the talks (where there 3 things?) Do they need more IDs?
EK: Issue 1: Can you send below or above a TFRC rate? - Could be done.
EK: Issue 2: During slow start or after slow start can you send more
after an idle period (e.g. more than twice)? - Research.
Probably not one I would choose to do.
EK: Issue 3: Variable packet sizes.
MW: I don't think CCID3-thin should be done now. I think the WG is
busy, and should do its work. The point is that we now know this
can be done, we can come back to this later.
AM: TSVWG would like someone to work on variable size TFRC - This is
within vision, but good research. Now is a good time to do this.
There's no reason to finish straight away. But, we also do not
need to do it here!
AF: Could it be done somewhere else?
AM: Yes, TSVWG could do it. Especially since we now have time, given
TCP will be handled by a separate WG.
MH: We don't have to close WGs, because this needs to be done. They
can work on the job until its finished.
AF: We want to think carefully, before we start accepting all new
work items under the current charter.
MH: DCCP work should be done here, not somewhere else!
AF: Right.
SF: On Issue 3: Variable packets is a good topic, and has been on my
list of things I'd want to do for some time, and I'll work on
this. On Issue 2: It's research. On issue 1: It's not a big
deal - its a change to the CCID.
AM: CCID3-Thin: How hard is it to get a user profile? Figure out who
wants to use it? How do we do this?
AF: So, should we defer adding it as a WG item? - Writing CCID3Thin
was a good thought experiment, and we learned it can be done. If
we leave it for a moment, then we can leave it as open, while we
work on the other things.
EK: CCID3-Thin is a simple draft that does not require much work,
it's within scope. We can do it here. We could do several, if we
need for different use cases.
Q: Should we take it on as a WG item with a long-term schedule?
AM: I worry now about several versions of 3Thin - That sounds like
you will be introducing interoperability problems.
EK: We don't expect 100's of profiles, it could be a small number.
AM: It's still risky, options are problematic. We have had bad
experience of profiling anything in the telephony space - usage
profiles have not been good - Adopting it today is not good,
let's think about how to express the task and come back to this.
Bob Braden (BB): I am deeply impressed by the way DCCP is a
swiss-army knife of a protocol. RSVP was hard to sell because it
was too complicated, let's not do that again. Think about this
ID as a proof that a sensible subset exists.
TP: I would not like to see a whole bunch of 3Thin profiles. We need
one.
MH: I'm agnostic on adopting this. I can think of reasons for not:
(i) It requires state machine changes - several profiles could
wreck the design of a DCCP server - a good reason for not doing
too many. (ii) CCID4-Thin could be just on the horizon -
variable sized support may be needed. Its a good case to wait,
EK: I hear it is good to look at this, at least to think about it.
- No decision taken to adopt this.
------------------------------------------------------------------------
--------------------
5. User Profile (Tom Phelan)
Suggestions on what the user guide should look like.
Inputs requested: scenarios; which CCIDs to use; etc.
AM: Thank you for this contribution!!
AF: How many people are following the WG mailing list and drafts?
Response: ~two dozen
AF: How many people will be Seoul at next IETF?
Response: ~one dozen
------------------------------------------------------------------------
Meeting closed at: 17:18
==============================================================
|