WG Chairs: Thomas Phelan tphelan@sonusnet.com
Gorry Fairhurst Gorry@erg.abdn.ac.uk
jabber: dccp@jabber.ietf.org
? 1. Agenda Bash
Scribe: Aaron Falk
Jabber scribe: Distributed
1. Agenda Bashing (10 minutes) - Chair
* Agenda changes
* Election of Scribe for Proceedings
* Jabber Scribe
2. Document Status (5 minutes) - Chair
* Milestones.
New WG I-D on DTLS (approved)
* Documents in Last Call - None.
* Documents Completed Last Call - None
* Documents in IESG/AD Review - None
* Documents in RFC Editor Queue:
draft-ietf-dccp-tfrc-voip
* Published RFCs in period - None.
3. Errata Status
* DCCP CCID-3 (Eddie Kohler, 5 minutes) (presenter: Chair)
4. Implementor feedback (Arnaldo, Andrea, Ian, Gerrit, 10 min) (presenter: Chair)
* CCID-3 evolution?
5. Active WG Drafts
* RTP over DCCP (Colin Perkins, 10 min)
www.ietf.orgdraft-perkins-dccp-rtp-01.txt
* Faster Restart (Eddie Kohler/Arjuna Sathiaseelan, 10 min)
www.ietf.orgdraft-ietf-dccp-tfrc-faster-restart-02.txt
* TCP Friendly Rate Control (3448.bis) (Sally, 10 min) (presenter: GF)
6. Related document from other AVT WG
* TFRC/RTP (Ladan Gharai 10 min)
www.ietf.orgdraft-ietf-avt-tfrc-profile-07.txt
7. Individual Submissions
* DCCP CCID4: TFRC with Small Packets (Sally, 10 min) (presenter: Chair)
* Service Codes (Gorry Fairhurst, 10 min)
* Quick-Start for DCCP (Arjuna Sathiaseelan, 10 min)
* CCID3 Drops (Eddie Kohler, 10 min) (presenter: Chair)
? 2. Working Group Status
Charter is unchanged.
Milestones: next is WGLC on "RTP over DCCP" as PS.
Document status: TFRC-SP in RFC Ed queue
? Individual Submissions:
draft-phelan-dccp-dtls-01 recently adopted as WG item, no expected changes to draft when republished as a draft-dccp-*, moving to WGLC as soon as re-published. Tom will check the use of Service Codes is consistent with other work. There are 2 committed reviewers.
ccid3-drops: nothing today.
serv-codes & dccp-qos: discussed later today.
? 3. Errata status for CCID-3
Two errata submitted, thought to be well-founded, new text proposed, but after review text is now thought to be no clearer and the fault lies with TFRC. tfrc-bis document will address clarifications.
Second errata was to say you measure RTT at the sender during the initial connect phase. Not much feedback. Expecting to close this item following meeting.
? 4. Implementer Feedback
Linux 2.6.20: Current status of DCCP.
Slides by Gerrit Renker & Ian McDonald. Presented by Gorry Fairhurst.
Outline: status, experiences, next steps & conclusions.
Work since last IETF focused on matching RFC compliance to specs, TFRC performance to theory, and behavior to user expectation.
Code: Arnaldo's DCCP framework (very mature & high quality), CCID-2 from Andrea (seems to work, not touched), and CCID-3 (code and spec current work).
? Additions to match RFC:
Service codes & partial checksums.
Larger initial windows (RFC 4342 5.)
Idle and application-limited periods (RFC 4342/TFRC.bis).
Using an RTT estimate from 'Request" exchange (not explicit in RFC 4342).
? RFC compliance gaps (not currently supported)
No current ECN support.
No loss intervals, no history discounting.
CCID3: No support for loss intervals, history discounting, presenting oscillations.
Need to complete gap analysis with RFC - may help understand if CCID-3 must be updated.
? Next Steps
Documentation & extension for socket API e.g., changing CCIDs via socket options
? Availability
Linux 2.6.20 is available.
Merging of further fixes planned for March, about 75 patches in the pipeline.
These new patches are on list/website, but not yet in the Linux release.
? Experience
Built-in kernel instrumentation (shown: dccp probe plots) for performance analysis.
One highlight of current work was uncontrollable speeds in CCID3: admits of GB speed (on 100MB interfaces), but no congestion control; limit of controllable speed given by t_gran. Implementation feature that is being addressed.
Idle Periods: Need Guidance.
? Open Issues
Accumulation of Send Credits (not intended by spec).
Window Counter RTT sampling (affected by packet compression from router/interface queuing).
? Conclusions
Many bug fixes so far (not all committed to mainline yet, see mailing list dccp@vger.kernel.org).
User/application experience missing (although paraslash audio streamer runs on dccp).
? Discussion
Lars: We are (Nokia) starting work on an independent implementation of DCCP.
Gorry: Is this independent?
Lars: Yes, different operating system also.
Aaron: It would be good to have a web page/wiki that lists various implementations and also applications to encourage interoperability work.
Gorry: I would like to see a WG link to a page that tracks this.
Gorry: WG has an active work item to maintain TFRC
Gorry: There is no work item to capture CCID3 divergence from TFRC. What should the group do?
Lars: All you need is a new draft; but it is not clear how TFRCbis and CCID3bis should progress.
Gorry: We could open a Wiki or something to capture implementation and interpretation experience.
Colin: This depends on TFRC over RTP draft progresses.
Gorry: The WG should revisit this issue after we have discussed the TFRC/RTP draft.
? 5. Active WG Drafts
? User Guide & Media Guide, Tom Phelan
Tom: User guide: Recommendation is to halt work, pending further experience, taking it off the list of milestones.
Gorry (as WGChair): We have an expired document with a WG name that does not reflect what we have expected in the WG. People could then contribute (later) to a better document.
Lars: Implementers are contributing directly on spec, content expected for user guide is not going into spec.
Gorry: I suggest revising the draft with some notation of what has recently been discussed, so that the document may form a useful input to future work.
Tom: Marking it dead seems sufficient.
Aaron: I am concerned about losing guidance to applications developers.
Colin: People are developing application experience and documenting in other places; may be too early to write this document; maybe revisit this in 2010?
Tom: I agree to removing the milestone and letting a document emerge in the future.
Gorry: We will validate this with the list, and seek to remove the milestone.
Lars: The charter will allow this later work.
Tom: Media guide has some material; will publish a new version; then the WG can evaluate it's future.
? DTLS over DCCP, Tom Phelan
Tom: I shall revise the draft with new service codes, and issue as a WG item.
? Colin: are you following the RTPsec BoF?
Tom: No.
Colin: We should also look at RTP over DCCP and SIP over DCCP with security, many drafts.
? RTP over DCCP, Colin Perkins
? Changes since -03
SDP requires new protocols to define a namespace for the media formats / MIME subset.
Clarifications to the draft on RTP on TFRC profile.
Editorial updates.
No open issues, done as far as I know, ready for WGLC.
? Discussion
Arjuna Sathiaseelan: On RTP data packets during idle (section 4.1), the drafts says send a packet every 15 seconds. Based on assumption that DCCP does not probe during silence. Faster Restart does use DCCP probing and the draft should mention that.
Colin: I have no issues with saying RTP does not need to do this when DCCP is probing.
? Colin: I have a comment on Faster Restart later.
Gorry: No need to hold up WGLC on that, Arjuna: Please send that comment in during WGLC.
Colin: I might be able to update the draft before WGLC with that if Arjuna sends a comment.
Gorry: I will start WGLC as soon as a new revision is republished.
Lars: Please make sure any reference to Fast Restart is informational since this doc is PS.
Gorry: The text should cover all DCCP CCIDs not specific ones.
? Faster Restart, Arjuna Sathiaseelan
-02 version
Motivated by TFRC limitations: Gradual restart after idle period and sender rate limits on bursty applications.
Assumptions: If sender has achieved rate X, then after an idle you can rapidly return to previous rate.
? This updates the last rev of the document.
Updated introduction to clarify applicability.
? Added probes to maintain RTT
Colin: This overloading will inhibit application keep-alives which are needed; we should add some way of doing both when needed.
Arjuna; OK.
New Receive Rate Length.
New variable X_active_min_rate: minimum restart rate allows by Faster Restart.
Updated pseudocode.
Planning to perform simulations based on the revised draft.
Definitions for "data-limited" and "idle periods", other things need definitions as well.
Gorry: terminology needs, are they common to all DCCP?
Arjuna: yes
? Discussion
?Colin: I think we need to differentiate keep-alives at the application and transport level. Can we identify one with an option - and the other as 0-byte data?
?Magnus: What is considered 'small packets'?
Arjuna: Needs to be defined.
Magnus: I am concerned about MTU interactions (i.e. for large MTU values, 9 KB, etc).
Arjuna: Anything smaller than 576 should be considered small.
Collin: Unsure.
Arjuna: We do need definitions.
Colin: The title is about TFRC, but you are talking about CCID3; We need to clarify which.
Arjuna: I agree.
? Gorry: to Colin: What semantics are you expecting for packets of zero length delivered to apps?
Colin: I do not know how this will be represented in the receiver API, does not seem the normal socket API. However, there is value in getting a keep-alive at the application.
Colin: Good question.
Gorry: Will the application be told this is present? or discover on it's own that transport is alive?
Craig White: Maybe we could set a status bit to say a keep-alive had come-in? Interested application could see this.
Colin: I was thinking about RTP gateway scenarios where keep-alives preclude needing STUN.
Tom: We need to distinguish between liveliness of applications and liveliness of transport connections and liveliness for (firewall) pin holes.
Gorry: Arjuna was just using them to validate his congestion window?
Arjuna: Yes.
Gorry: We seem to have many functions using one mechanism...
Arjuna: I believe that application keep-alives and transport keep-alives should be synchronized somehow.
Colin: This depends whether we think there is a useful application semantics for sending a zero length datagram. The reason I recommended this in the RTP draft was because some CCIDs do not do it and some NATs need it to keep the NATs open. If all CCIDs did this, it would be OK.
Gorry: If there are different reasons for keep-alives, we need to better understand what each layer is trying to achieve. Concerned about interactions.
Colin: I was using this because of missing features in previous *transports*. If the transports did the right thing, applications would not need to do it.
Mark H.: Maybe we should add a DCCP option for transport keep-alives, enabled by DCCP, that enables keep-alives and is unambiguous.
Lars: Disagree that this should be a DCCP-layer option. Generally, the application should be aware of whether a keep-alive is needed.
Tom: We now have three usages.
Magnus: One could also think about what it means to have a DCCP-wide keep-alive option.
Lars: I do not think we should have a DCCP-Layer keep-alive. In the end the applications decide these things.
Aaron: We may be confusing cause and effect.
Magnus: What about mobility?
Aaron: Does it do harm to leave it on?
Lars: We have a range of links (e.g. wireless) where this traffic may be significant,
Gorry: Lets have a short discussion on the list should see if we have understood all the issues. We need to generate an email with all the use cases for keep-alives.
Mark: Concerned that we are overloaded the semantics. It's too early in the life of DCCP to do this. We might need a draft on keep-alives.
Arjuna: We also need to answer the question of what you do when you get a keep-alive.
Gorry: Lets start with the list should and then see whether we need a draft.
Mark: There may finally be a need for a draft on keep-alives.
? TCP Friendly Rate Control (3448.bis), Sally Floyd, presenter: Gorry Fairhurst
Motivated by accumulation of experience and growing errata.
Current document is at version -01.
? Changes from RFC3448.
This incorporated RFC3448 errata.
Larger initial windows, per RFC3390, now to be aligned to RFC4342 (CCID-3).
It clarified how average loss history is calculate when receiver has not yet seen 8 loss interval.
Added more about estimating average segment size.
? New changes
Initializing loss history when first packet is lost or ECN-marked.
General clarifications.
Open issues are listed.
? Changes in -02b (dated 3/16)
Addition of options "limited receive rate" variable in feedback packets.
Clarified accumulations of 'credits' during idle.
? Changes that could be done
Re-read RFC4342 to make sure again that everything is included that should be.
Re-read research papers on TFRC for additional changes or observations.
Input from WG, please tell the authors of any unclear sections.
? Discussion
Arjuna: The limited receive rate is incomplete; this come out in the next revision.
Tom: How does this relate to CCID-3? What does it say in CCID-3 about tracking changes in TFRC?
Gorry: CCID-3 is a separate specification. It will track changes in the basic math of TFRC (as reflected in IETF documents), but there is no standards dependency on TFRC. However, the implementers are saying they need to take things from RFC 3448 to implement.
Colin: and vice-versa...
Lars: It would be good to tease the documents apart to make TFRC to be the basic rate-control algorithm and make CCID-3 the embedding of it into DCCP.
Mark Handley.: TFRC RFC is intended to be a rather protocol agnostic definition of the congestion control algorithm. DCCP has unique constraints based on the specifics of the protocol, that need to be mapped. You probably can not make TFRC so general that it maps directly into DCCP.
Ladan: This is related to my work on TRFC/RTP.
Tom: ... but, recall that Mark Handley is arguing for a CCID-3.bis.
? TFRC/RTP, Ladan Gharai
Draft is mostly about exchange of rate information between senders and receivers.
Application-layer version of TFRC, this presents more tighter coupling with application.
Existing solutions exist for NAT-traversal.
Designed to give experience with using TFRC to the community.
This used to be a 'profile' but now relies on AVT documents: RFC4585, 3536.
? Why use TFRC with RTP/UDP vs. DCCP?
Congestion control at the application layer, rather than the kernel (may be a good thing, or a bad thing).
Application TFRC can better merge timing requirements of media and transport.
Differences between RTP with TFRC and DCCP/CCID3 listed...
? Aaron: What is the RTP/TFRC typical minimum?
Ladan: The TFRC/RTP size is 100 bytes per packet (before data), but do not need all that information
Compared to DCCP of 50 bytes (min), but both can grow with variable sized fields.
? Discussion
? Tom: Is this based on 3448.bis?
Colin: Yes, at least the last version I read.
Gorry: I think it would be good advice to read 4338.bis, since this will obsolete RFC 3448.
Tom: This group is concerned with TFRC, but not the RTP issues that lie elsewhere.
?Gorry: This work pre-dates DCCP. Now that DCCP is a PS, what is the status of this work?
Magnus: This is chartered work in AVT. There is still a question about getting DCCP through in a real network (thinking about NATs, Firewalls). It is still worth pursuing this.
Lars: It was never the intention to say only DCCP can use TFRC.
? Aaron: Is this open? Is it in use by others?
Ladan: It is freely available. No-one else is using it now, as far as I know.
Arjuna: Limited receive will likely change the TFRC feedback packet.
Ladan: That, I need to know.
? Colin: This comes back to what to do about the TFRC spec. It will be confusing for AVT if CCID-3 changes need to get into AVT.Is there commitment to keep TFRC a clean spec?
Tom: Yes, this is understood. Two consumers of the algorithm mean keeping the spec clean. In the future, this probably will lead to a CCID-3.bis.
Gorry: I do not think it is possible (or desirable) to rip out the TFRC pieces from CCID-3.
Mark: In some cases there were deviations from TFRC, because CCID-3 needed changes, it does not mean TFRC needs to change.
Tom: Some issues related to the protocol, and some to the protocol.
Gorry: Thanks Ladan for keeping us up to date on this. We do need to start collecting what has changed and what are issues in CCID-3, to see if a CCID-3.bis is needed.
? Individual Submissions
? Service Codes, Gorry Fairhurst
Version -03
32-bit value in DCCP-Connect (RFC4340), IANA Registry specifies value but is currently mostly empty.
doc discusses role of SC in DCCP, uses of SC, how to implement, use of SC by middleboxes, and motivates the case for non-zero SC.
Implementation options: minimal support (not recommended), standard support (well-known ports, recommended), or enhanced support modified using inetd, - please send comments on this.
Example of some small services: echo, daytime, chargen, time, perftest.
The draft clarifies that SC is used for define use cases, not to describe vendor protocol versions.
This may need to work on API.
? Discussion
Mark: It should absolutely become a working group draft; I didn't do a good enough job initially on the use of SC, although we were waiting for more experience; It seems like now is a good time.
Tom: has anyone read the draft? (some have).
Lars: Let us do a quick hum... (all hums for making a draft, no hums against)
? Quick-Start for DCCP, Arjuna Sathiaseelan
Similar to Quick-Start (QS) with TCP (RFC4782), an end host requests QS at the beginning or middle of a connection to send a specific rate.
The draft states that QS should not send an additional request within four RTTs of the last request.
QS requests processed identical to TCP.
? Some additional adaptations to make QS work with CCID-3, a natural fit since both QS and CCID-3 are rate-based.
Added a QS-validation phase to affirm capacity used by QS packets did not introduce congestion. Sender tentatively permitted to continue sending at WS sending rate. Basically it ignores (positive) feedback packets for up to 1.5 RTTs, then transitions to standard congestion control mechanisms.
Some simulation results were shown for CCID-4.
? Protocols issues:
After idle, must requested QS rate consider current loss event rate?
Need to consider implications of alternate paths, etc
Need to consider implications of over-shoot.
Next revisions: adding text for CCID-2.
Question: Is this draft to find a home in TSV WG or the DCCP WG?
? Discussion
Lars: Since this modifies DCCP, it should be presented here. It can also be presented at TSVWG. It is more important to have these folks in the room.
Gorry: (with WG Chair hat off): I am concerned that if we proceed with DCCP QS and there were other proposals, such as SCTP, they should be coordinated.
Lars: Let us start here.
Tom: What is the status of QS?
Lars: TCP QS is an experimental RFC.
Tom: And this is intended for Experimental to?
Gorry: Yes.
? Gorry: Some period of time after you have congestion in the network, can you then ask using QS about increasing your rate? - Once you think the congestion may be gone?
Lars: This is a QS question, independent of the protocol...
Gorry: It is.
Mark Handley: My concern is that doing this every 4 RTTs is too frequent. If you are getting valid feedback continuously, you should not be using this every 4 RTTs.
Gorry: So, we thought 4RTTs was long, but in this case it would not be.
Mark: I f you think your feedback is /may not be wrong, then you might do it, but otherwise you should not do it. If you think there is a reason why things have changed, it may be OK.
Colin: You probably should use this at the beginning of the connection, or after an idle.
Mark: If TFRC history discounting has kicked in, this makes sense, to remove out-of-date history. otherwise you should not use this.
Gorry: This is the sort of scenario we are seeking. This is draft-00 we'll revise and bring this back.
Lars: So, much of this discussion has been about QS questions - these may be good to take to TSVWG.
Tom: I confirm, the DCCP issues can be taken here, the QS issues should be taken in TSV.
? Slowly-Responding version of CCID2, Sally Floyd, presented by Gorry Fairhurst.
This is a new draft (to be submitted soon), Sally is looking for collaboration.
Additive (slow) increase of 1/5 MSS, multiplicative decrease to 7/8 of cwnd.
Mark: The receiver mechanisms are the same as CCID-2, so this could be a variant, not a new CCID.
Gorry: I'd like to see the draft before we start calling as to whether this is a new CCID, etc.
? Discussion
Colin: How many CCIDs so we have? Could we possibly partition the CCID number space into experimental and likely to be widely deployed?
Gorry: This is a thought we need to look at. This should be discussed at a future meeting.
? Bob Briscoe: If we take this to its logical conclusion, we end up with inelastic flows that continue the same as TCP and hardly adjust. This would cause a lot more congestion than TCP, see my draft on fairness.
Mark: I think the dynamics of this are equivalent to TFRC - we discussed something similar about 5 years ago.
Bob: I think this is worse than TFRC.
Arjuna: TFRC is rate-based, which is a difference.
Bob: ...but, the dynamics of TFRC are wrong.
Mark: Then your argument is with TFRC.
Bob: I think this is worse.
Gorry: Please do respond (again) to Sally when she submits the draft for us to read.
?WG closed.