DCCP Working Group Meeting,
IETF-60, July 23, 2007.
Notes from Sally Floyd and Tom Phelan.
* Document Status - Gorry Fairhurst
The RTP/DCCP document is with the RFC Editor, awaiting
normative references to be published.
The WG milestones were updated.
It was noted that he was looking for someone to contribute
to a Media Guide.
The User Guide is also looking for implementation experience
with the aim of publishing this in 2008.
Lars Eggert (AD) asked if someone would write a document on
middlebox considerations for DCCP, for the BEHAVE WG.
This would be about how NATs should modify DCCP packets that
traverse them, mirroring other BEHAVE documents about UDP
or SCTP. The DCCP-specific issues will include service codes.
* TFRCbis
draft-ietf-dccp-rfc3448bis - Sally Floyd
This was revision -02, intended to obsolete RFC 3448.
TFRCbis has larger initial sending rates that TFRC,
reflecting changes in TCP.
Three main changes from -01:
* Mechanism for responding to feedback after an idle period.
* Response after idle and data-limited periods.
* Use of unused send credits (the sender can now save
unused credits for one RTT).
Mark Handley: What will the app writer do about data-limited
periods, given what is suggested for TFRCbis?
Should the application pad the flow so that it will get
what it needs when it (later) needs it?
That is what I expect it would do.
Sally: You could get more loss.
Mark: This could be a natural reaction. We should think about
these incentives to pad the sending rate during idle periods.
Sally: In data-limited period, the receive rate does not
restrict the sending rate.
Sally: By the same argument, apps would pad TCP data too.
Mark: The TCP ramp-up is faster, so there is less incentive.
If you are using TCP, you are not real time, so a fast
ramp-up less important.
Sally: Something to be addressed in another document.
Colin Perkins: It has been suggested many times, it will
happen.
Randall Stewart: If you are not being a good citizen, why
use DCCP in the first place? Why not just use UDP?
Mark: The application is just trying to prepare for the
future data it may have.
Sally: I would like to see WGLC by the next IETF.
Gorry Fairhurst: Is the current version of TFRCbis stable?
Sally: There are two changes to make, listed in the slides,
and then it should be stable. A new version will be soon.
Gorry: We asked for simulation work to support, and now we
have this. Feedback and questions to the list are now needed.
* TFRC/RTP
draft-ietf-avt-tfrc-profile - Colin Perkins for Ladan Gharai
The presentation showed changes since revision -07. There have
been a lot of work to tidy the draft. Section 3 has been
updated on RTP/DCCP compared to application-level TRFC.
Feedback is from the WG requested on these new sections.
Question: How do you decide how many feedbacks to send,
especially when working with an asymmetric capacity link.
Colin: If you know the expected data rate, then it is not
a problem.
Magnus Westerlund: What is the relationship between RTP
sending rate and RTCP sending rate?
Gorry: Are there any complications from using 3448.bis
instead of RFC 3448?
Colin: There may be some changes in the information to be
provided, but other than that, I do not think there are any
issues.
* Faster Restart
draft-ietf-dccp-tfrc-faster-restart - Sally Floyd
The draft is reasonable stable except that simulations are
needed on the worst-case congested scenarios. The ping
during idle period does not seem required, this may be
changed. Simulations then needed with new algorithm.
Colin: For the ping during idle times, what happens when
the RTT is much smaller than the frame rate of codecs
(e.g. every 40 ms)?
Sally: Our plan is to remove the "MUST ping", and make
it optional or omit it completely. Our inclination is
to take it out.
Colin: If we leave it in, we need to specify the interval
better.
Sally: OK. We need to specify a minimum interval, if we
keep keep-alives.
Colin: The draft says that the API MUST NOT report received
zero-length packets. This seems to create a strange
non-symmetric situation.
Sally: Transport and application keep-alives are different.
Colin: There are two cases - application and transport.
Gorry: We spoke about possible formats for the keep alive
packet at the last IETF, we still need to define how
DCCP will treat the transport keep-alive (if any).
Tom Phelan: I thought we agreed that apps could send and
receive zero-length data packets? If a CCID needed to
send keep-alives, it would need to create something else.
Mark Allman: Is this a general principle?
Could I use Faster Restart in TCP?
Sally: Not until simulations are done exploring worst-case
scenarios, but then if it is OK, someone could propose
this for other transports (e.g. TCP).
Mark: Could part of the worst-case simulations could be in
the context of TCP?
Sally: The worst-case simulations would be of a congested
link with everyone using Faster Restart.
Lars: What assumptions are you making on the path? Maybe the
path could change during an idle period?
Sally: The allowed sending rate takes the last feedback packet
into account. If you have loss then it went down. Should
we add something that says that loss in the last feedback
packet effects what you can do when you restart?
Lars: Maybe.
Sally: We could add more checks on this.
Lachlan Andrew: Should the increase after the idle period be
linear instead of exponential with a higher starting point?
Sally: I would not want to go faster than quadrupling the
old sending rate.
Lachlan: Should the quadrupling slow down as you approach
the old rate?
Sally: That is possible, but it may not be worth the added
complexity.
* Service Codes
draft-fairhurst-tsvwg-dccp-qs - Gorry Fairhurst
This is WG revision -00 of DCCP Service Codes. There is still
work to refine the recommendations and some speculative text
to stimulate discussion. A new revision is expected soon
after the IETF.
Mark Handley: Multiple Service Codes on the same port?
Mark reviewed his recollection of the past history of
Service Codes, explaining why there is now the ambiguity
between ports and Service Codes. A long time ago, the spec
did not have ports at all, to avoid the issue of reusing
ports for other places. Eddie suggested we change this to
have ports that look like TCP, UDP - so that we can traverse
firewalls, NATs etc.
The motivation was that any application that wants one should
be able to have a Service Code. There is a shortage of
well-known ports, so we need to be able to allow multiple
Service Codes bound to a single port.
Question: What happens if the port is in use?
Gorry: A DCCP Reset is sent in response to a bad
Service Code on a port.
Lars: In the mean-time, people have started to use
DNS SRV records, where there is no well-known port.
There is arguably a greater push behind this that for
DCCP Service Codes. Should we assume DCCP Service Codes
have failed, and give them up?
Tom: SIP implementations have widely used SRV records.
Mark Handley: These are two mechanisms for two different
problems.
Lars: There are problems with deploying any new transport
protocol, and thought needs to be given to the problems
of NAT traversal introduced by DCCP Service Codes. Even
simple changes to socket handling can impede deployment.
Mark: The main different is how you handle connection
set-up. This is only a small change. This is protocol-
specific issue in any case.
Comment: Understanding the app can be helpful to middleboxes.
Colin: The Service Code is only in some packets, not all,
applications can also lie.
Gorry: Middleboxes also can not believe well-known ports.
Mark: The intent of Service Codes was never to be
cryptographically secure, or to prevent applications
from hiding.
Colin: Middleboxes will not believe the Service Code value,
for the same reason that they do not believe well-known
ports.
Mark: It depends on what kind of middleboxes you are
talking about. The Service Code is not addressing security.
Gorry presented three models for using Service Codes that
had been suggested - were these acceptable?
(1) Minimal support, also adds complication.
(2) Standard support.
(3) Enhanced support: Mapping SC to ports.
Mark: Trying to have a wild-card service code was against
our intention for Service Codes.
Colin: Do applications listen on ports, or on service codes?
For (2), Mark said that a single port can have multiple
Service Codes. There can be multiple Service Codes for a
well-known port.
Colin: Do applications listen on a port or a SC?
Gorry: Applications could let a range of ports be used
with any specific SC - method (3) would allow this.
Lars: "Everyone now knows why we need this draft."
Gorry: Should we allow a service code of zero as a default
Service Code?
Lars: Does the port imply the Service Code will use?
Gorry: Could do (but that is a choice).
Mark: I'd like to define a new method (2b), in which a SC is
registered with IANA on a well-known port. IANA does not
guarantee each SC has a unique port. SC=Foo and SC=Bar
could use the same port.
Gorry: Correct. So the socket/end host has to deal with this.
Mark: yes on the accept.
Gorry: OK, I'll add this as a case.
Colin: Part of the problem is the socket API. You need to
supply both port and SC when you bind to a socket.
Gorry: yes - you can assign both in two different operations
or one.
Gorry: My biggest question is should we allow a SC of zero?
Colin: The current API needs you to do this.
Gorry: You could return an error (if you do not specify a SC).
Mark: I am not saying that this is an inherently evil thing
to do. We can allow it. But we do not recommend it.
Lars: It would be very nice to come up with a scheme that
does not require requests to IANA (e.g., for registering
Service Codes).
Mark: It should be possible to do a dual registration of SC
and ports if both are ascii.
Gorry: These are different formats.
Tom: Yes, SRV records do not map directly.
* DTLS over DCCP
draft-ietf-dccp-dtls - Tom Phelan
This is now more or less complete, and near a WGLC.
Colin Perkins: What do you say about Service Codes?
Tom: An application MUST register a new SC value for DTLS.
Colin: I agree this is the simplest case. Have you looked at
ICE and DTLS, and that both run in parallel on the same
port using STUN. We need to make this simple.
Tom: I have not yet looked at this.
Colin: We do not want a new service code when we use ICE.
Gorry: Once we have a new revision we can move this to WGLC.
* TFRC Media Guide
draft-ietf-dccp-tfrc-media - Tom Phelan
It offers strategies for applications to use DCCP. This needs
some new people to read it, and to see a way forward.
Gorry: Who has read the document?
Gorry: This needs more inputs from the WG.
* Implementor's Status - Gorry Fairhurst (no slides)
The DCCP implementation is being taken out of the main tree
for Linux for the moment. It will be merged back when the
code and Linux API is more stable.
* Quick-Start for DCCP - Gorry Fairhurst
This was revision -02 of the Draft. This revision described:
* QS with CCID-2
* QS with CCID-3
It also added a new concept, the QS Interval. Is this ready
to adopt a WG draft?
Mark Allman: The draft specifies a minimum interval of a
second? I do not see QS needing to do this every second.
Gorry: I don't see that either, it was the smallest number
I could find. Should it be longer? What about an interval
of ten seconds?
Mark: That is better. It may merit some investigation
of what that number should be.
Gorry: OK, we shall look at this.
Tom: Who has read the document?
Tom: I would like to take the question of whether this should
become a WG draft to the list after this meeting.
Lars: There are two issues, the QS evolution and the DCCP issues.
Should this be in tsvwg instead? Wherever it is adopted it
will need to be WGLC in both groups.
* CCID4 (DCCP Small Packet TFRC)
draft-floyd-dccp-ccid4 - Sally Floyd
This describes how to do SP variants of TFRC for DCCP. The
current draft predates the work on TFRC.bis.
Gorry: We shall ask the list for feedback (positive or
negative), to see if this may be adopted as a WG draft.
* CCID3 Dropped Packets option
draft-kohler-dccp-ccid3-drops - Sally Floyd for Eddie Kohler
This draft describes a protocol update for CCID-3, that
is needed for CCID-4.
Gorry: Who has read either of these documents?
Colin: I think this work needs to be done.
Sally: Both drafts can proceed quickly if it is adopted
(there no need to wait until next meeting for WG Last Call).
Gorry: We need this to be adopted, and then to get people to
read this.
Sally: The documents are very short (especially the last),
comments are welcome.
* Other protocols planning to use DCCP
There are two other active documents both in other WGs that
plan to use DCCP: one for SIP, one for GIST. See the ID-tracker
or slides for a pointer.
Tom: Thanks for coming, and look forward to meeting you again
in Vancouver.