Datagram Congestion Control Protocol WG (dccp)
THURSDAY, 10th November 2005 at 13:00-15:00

CHAIRS: Lars Eggert 
        Tom Phelan  

Notes by Gorry Fairhurst .

I. The agenda was bashed by the chairs.

II. Status of Internet-Drafts

The set of drafts below are now done and with the RFC Editor:
        draft-ietf-dccp-spec-11 (Proposed Standard)
        draft-ietf-dccp-ccid2-10 (Proposed Standard)
        draft-ietf-dccp-ccid3-11 (Proposed Standard)
        draft-ietf-dccp-proble-03 (Informational)

There is currently no IANA registry for DCCP numbers. The authors need
to talk to IANA about this. Allocation procedure will be the same as
for UDP.

The following WG drafts are active:
        draft-ietf-dccp-tfrc-faster-restart-00
        draft-ietf-dccp-tfrc-media-01
        draft-ietf-dccp-tfrc-voip-02
        draft-ietf-dccp-user-guide-03 (Expired)

Gorry Fairhurst: Can we make sure the whole WG is aware of the small
change to the Spec that resulted from the formal method review?

The Chairs suggested that Eddie Kohler sends an email, reminding the
group of the change made to draft-ietf-dccp-spec-11 since WGLC (already
sent to the list).


III. State of the WG
Gorry Fairhurst has taken the job of WG Secretary for DCCP.


IV. Implementation status (Lars Eggert)
There are two actively maintained DCCP implementations. Both are based
on the original Lulea code. The WG is interested to hear of other
implementations.


IV-1 DCCP Implemenation on NetBSD (Yoshifumi Nishida)

Current implementations exist for Net BSD 2.0 and Free BSD 5.4. An
OpenBSD implementation is under development. The work is based on Free
BSD from Lulea, and supports CCIDs 2,3. Some interop tests have been
performed with Linux, which discovered some issues (Feature
Negotiation, Elapsed Time Option). Feedback was requested on the
implementations. For more information see:
ftp.kame.net/pub/kame/snap

Randall Stewart: The Kame project will finish in April, will the DCCP
implementation continue?
Yoshifumi: It will continue.


V.  Status of WG Drafts

V-1 TFRC Media (Tom Phelan)
draft-ietf-dccp-tfrc-media

The draft had been updated based on comments received including
comments from Colin Perkins. No additional comments were received from
the dccp list. The authors asked if this I-D was ready for WGLC.

Colin Perkins: Have you implemented any of the things in the I-D?
Tom Phelan: No.
Colin Perkins: Maybe you should, before progressing this to WGLC.
Chair: Can people read and commit to a short review?
Sally Floyd: Implementation means a lot.
Tom Phelan: I will talk to implementors.
Colin Perkins: Implementation also requires some effort.
Steve Casner: If you think it is done, then we could start a WGLC and
ask for comments, but say that the WGLC will not conclude until
implementations are achieved.
Chair: We will come back to this at next IETF.

V-2 DCCP Users Guide (Tom Phelan)
draft-ietf-dccp-user-guide
After discussions in Paris, and production of the media guide I-D. The
current I-D now lacks content. The authors now recommend that this is
placed on hold awaiting more experience.

Gorry Fairhurst: One slight problem is that this is a WG item that is
out of date. It would be good for the authors to rev. the I-D to
reflect the WG plans for the I-D.
Tom Phelan: I'll take this as an action, and remove the stuff that is
no longer relevent.
Tom Phelan: The actual new text will take more time, and needs inputs
from implementors.
Chair: There is still time within the milestone, so this is OK. Offers
of help are appreciated.


V-3 TFRC VoIP Mode (Sally Floyd)
draft-ietf-dccp-tfrc-voip

Sally presented results following what was presented to the DCCP WG in
Paris. The conclusion was that the results for small packets were OK.
There is a wide range of buffer handling in routers. There was also
some evidence (from using the tbit tool with web servers) that in many
routers, small and large packets are dropped equally.

Matt Mathis: How much better is TCP with small packets, rather than big
ones?
Sally: Significant, TCP with large segments does not do well when used
over a path with byte-drop RED.

?: What is the x-axis?
Sally Floyd: Byte drop rate, sending flows and recording the rate (all
separate experiments).

Magnus Westerlund: It seems that above 6 kps, the various CC schemes
all behave the same. (i.e. the fair-share is less than 10 kbps).
Sally Floyd: Yes. The performance is only different when highly
congested (10% or above). VoIP-TFRC presents no difference when
congestion is low.

Tom Phelan: This data does not show the performance of competing flows.
Sally Floyd: There are other simulations that do. These were in earlier
version of the draft.

Colin Perkins: The presented data is for a 40 B header. This is not
what we expect for RTP using TFRC. How critical is the size of the
header?
Sally Floyd: I think the header size is not sensitive (even with
tunnels it is within a factor of 2).
Colin Perkins: OK
Tom Phelan: The RTP header is counted in the user payload.
Colin Perkins: I really think we need to change the name of the draft.
Sally Floyd: "TFRC with small packets" is fine for me.

Chair: Who has read the draft (same as in Paris)?
Chair: Is the I-D ready for WGLC for publication as Experimental?
The humm showed some people thought it was ready to go to WGLC.
Colin Perkins: Can we see the final draft first, before we make this
decision?
Sally Floyd: OK, we will do one more rev.
WG: After this I-D is ready, we can take this to the list.


VI. Discussion on next steps for DCCP (Lars Eggert)
Milestones need to be updated, based on the new work accepted in
IETF-63. The  Next Steps for the DCCP WG will switch focus from
specifying DCCP to enabling use of DCCP. There are a set of
presentations on this topic. Another issue is that interop testers have
also reported that NAT traversal needs to be described, and could be
another I-D.


VI-1 RTP over DCCP (Colin Perkins)
draft-perkins-dccp-rtp

Some signaling is needed before the RTP media flows can start (e.g.
using SIP or RTSP).
RTCP information sent with the RTP over UDP. SDP has a need to identify
the protocol type - and this implies some work to support DCCP.
Tom Phelan: Why is the list of supported types for DCCP different for
TCP than DCCP?
Colin Perkins: Some of these still need to be registered for TCP and
DCCP.

Jonathon Lenox: There was some discussion the AVT list that some
combinations do not make sense, e.g. AVPF used with TCP.
Magnus Westerlund: It makes sense to have feedback with all of these.
We need AVPF, even if we do not need the full set of functions
(including congetsion control).
Colin Perkins: AVPF can request application retransmission, etc. If it
conflicts, DCCP should take priority.
Steve Casner: Can DCCP congestion control compete with mechanisms at
the RTP level?
Colin Perkins: Unlikely that this is an issue, but there is potential.

DCCP also needs a service code attribute added to SDP. Is this
assignment one per application or for all RTP traffic? I propose we use
service codes for each application. The flows can all use a common RTP
port, and the service codes are used to differentiate the flows at the
firewall.
Tom Phelan: Yes, one per application.
Colin Perkins: RTP is a class of applications. We need a port registry
for DCCP.

Magnus Westerlund: RTCP feedback interval should be a minimum of 5
seconds. Some environments send much more.
Colin Perkins: Congestion control should take precedence over RTCP
scaling rules. If the session bandwidth changes - different in two
directions, this may be trouble, and one party can time out.
Steve Casner: For a 2 party session, you can disable scaling.
Steve Casner: RTCP provides receiver monitoring, but so also does DCCP.
If you do not use it for lip-synch, do you need to send it?  Does it
duplicate functionality in DCCP?
Colin Perkins: Not entirely, we need to think about the rules.
Magnus Westerlund: We should think about scenarios for conferencing
applications (star topology with a central node).
Colin Perkins: Yes, see later in the presentation.
Jim G: I find this work quite relevant.
Chair: Do the people in the room think we should do this in the DCCP WG?
(20 people for/ No people against)


VI-2 ADDCONF in SCTP (Randal Stewart)
draft-ietf-tsvwg-addip-sctp-12.txt

Randal described the approach used in SCTP for moving an established
flow between end-host addresses. Authentication mechanisms had been
introduced to prevent hi-jacking of connections in SCTP. Is this
suitable for DCCP mobility?


VI-3 DCCP and Mobility? (Pasi Sarolahti)

Pasi presented slides describing single-homed (simpler) and multi-homed
approaches. It should be possible to follow the lessons learned in
SCTP. Mobility adds new functions (an advantage to DCCP), but also adds
complexity. The proposal is to make DCCP Mobility an experimental
option, where implementers could decide whether to support it.


VI-4 Does DCCP bring advantages? (John Lockley)
John motivated the case for deploying DCCP, based on the advantages of
good mobility support.
Mobility also brings strange impacts on congestion control (reordering,
loss, significant change in rate, etc). This can cause complications to
real-time applications, and DCCP would benefit from being more agile.
There is also a lot of work in the Internet areas: SHIM layers, HIP,
multi-homing. The focus is different, and work also needs to consider
transport issues and congestion control.

Sally Floyd: There is some work on congestion control that can work
across changes in path characteristics.  One example is QuickStart in
the TSWVWG WG (draft-ietf-tsvwg-quickstart-01.txt).
John Loughney: Is QuickStart for DCCP defined?
Sally Floyd: This is not described in the I-D, but it is mentioned in
an appendix of the I-D. The detail would need a seperate I-D.
?: It could also be useful in cases where you wish to use both IPv4 and
IPv6.
Jonathon Lenox: If the aim is to keep an existing session at a server,
when a client moves, then the protocol (i.e. server socket) will
normally be the same. It is hard for an application to keep a session
across multiple network protocols.
?: No, it's just a socket issue.
Pasi Sarolahti: How much does this effect the base DCCP spec.?
Lars Eggert: Is this an option? - or does it require changes to the
DCCP base spec.?
Pasi Sarolahti: This needs investigation. The feature-negotiation may
be useful.
Tom Phelan: I think it can be added as an option.
Colin Perkins: I was one who argued against mobility in the base
specification (based on the complexity), but as an extension, I would
support this.
Tom Phelan: Is there energy and expertise to do this in the DCCP WG?
Will people write I-Ds?
Pasi Sarolahti: I will work on it, details need thought, may make an
I-D for IETF-65.
Bob Briscoe: I can volunteer Loiuse Burness as a reviewer.
Lars Eggert: Who in the room would support this as a Charter Item?
(10 people for/No people against)


VI-5 DTLS (Eric Rescola)
draft-rescorla-dtls-05.txt

Eric presented DTLS, an adaption of TLS to work with a datagram stream
(and using the initialisation vector defined in TLS1.1). The base spec
is in RFC-Ed queue, and there is an implementation in OpenSSL. There
are likely to be some issues with using this with DCCP: Need to merge
the handshaking to reduce latency; Retransmission of DTLS with CC needs
to be considered. I'd be interested to work on a draft, but need a DCCP
volunteer. Would there be volunteers to work on this from the transport
side?

Jonathon Lenox: I understand use-case for DCCP. What are the deployment
use cases?
Eric Rescorla: It provides a security method. It is an alternative to
IPsec.
Magnus Westerlund: Can we integrate this with the initial handshake,
during the feature negotiation phase (e.g. to know who is connected).
Could we combine with feature negotiation.
Eric Rescorla: Yes. This would require DCCP feature negotiation and
that was along the line I was thinking.
Tom Phelan: Application writers like TLS, because they get control of
the security function.
Chair: Who would like to see this as work within the DCCP WG?
(10 people for/No people against)
Chair: Who would support the work on this with Eric?
(3 people, 1 for reviewing)
Chair: Please email Eric if you are interested.


VI-6 Requirements for a CCID for Interactive Media (Tom Phelan)

The WG has two CCIDs specified, there are issues with delay-intolerant
applications. Should the WG explore more options to better fit the
needs of network applications?
There has been discussion on the mailing list and I-Ds on this:
        draft-burness-dccp-interactive-apps
        draft-phelan-mfrc
        draft-phelan-dccp-media

Sally Floyd: Are you trying to write the requirements for
commercial-grade interactive media or the range of applications that
DCCP may work with in general?
Tom Phelan: I'm interested in Internet Applications over the general
Internet. TCP-friendliness needs to be consider, although fairness may
need to be considered over longer periods.
Bob Briscoe: I think the problem of TCP friendliness is too focussed on
"what you get", rather than "what it costs" the network. It ought to be
based on the congestion you experience/cause, and the time period this
is measured matters, since it varies.
Magnus Westerlund: The question is what is acceptable: There is much
research here, but it may not be ready for the WG.
Lars Eggert: This work lies in the middle of a number of groups
including transport modeling RG, congestion RG, DCCP WG.
Colin Perkins: I see lots of fun research, but no engineering yet.
Sally Floyd: I could write an I-D that may take a different look at the
problem: requirements, evaluation, cost v. benefits in sending rate
adjustments, etc.
Chair: This discussion will continue on the list. If there are other
issues please do send them to the list.

Close of meeting.