Thanks to Ekr for taking the minutes! Send corrections to Tom and Gorry. DCCP Meeting Minutes IETF 65 March 21, 2006 1. Agenda bash (see web site) No additions to agenda. 2. Review of work items All drafts pending publication are now in Auth48 draft-ietf-dccp-tfrc-voip has passed WGLC - Tom is PROTO shepherd Lars Eggert will resign as chair. Gorry Fairhurst to take over as co-chair with Tom. 3. draft-ietf-dccp-tfrc-media (Tom Phelan) - We don't have enough implementation experience on this document so we're putting it on hold until we get some. - Colin Perkins: we don't have anything over DCCP but we do have experience with TFRC over UDP so we expect the experience will transfer. Hope to have feedback in the next few months. - Eggert: Linux and KAME communities are implementing specs and may get to these. - Tom: DCCP is in NS. 4. draft-ietf-dcp-user-guide (Tom Phelan) - Last text was extracted to be tfrc-media. Looking for input. Eggert - during last call there was some experience and input we'd like to put in the user guide, particularly clarifications for the loss interval and packet loss rate. We have a student with some data but it's not ready to show yet. a. Issue is packet size calculation (MSS or average?). It's not definite in the draft but you need to agree. b. Estimation of loss interval--you're supposed to average over 8. Some implementations screw this up if they have less than 8 samples. Sally - need to clarify things in the TFRC spec. Tom - I'm looking for an organizing principle for this. Will try to have a first draft of new organization by next meeting. Eggert - update milestones for user guide to "next meeting"? Tom - let's see how charter discussion goes. 5. Rechartering ideas Basic idea: - maintenance of core protocol of DCCP - modular extensions to DCCP - promoting the use of DCCP by upper layers Maintenance of DCCP: Move drafts along standards track. Make only tightly controlled, well justified changes. Extending DCCP: Identify extensions that would make DCCP attractive. Be open to other IETF WGs. Won't do new congestion control schemes but will support ICCRG by providing a deployment platform. Promoting DCCP: Specifications for other protocols over DCCP. Evangelism. Work in second two areas need buy-in from WG and maybe ADs before proceeding. Nonexclusive list of potential collaborators TSVWG, AVT, MMUSIC, BEHAVE, ICCRG, TMRG. Milestones: out to Jun 2007 and include mobility extensions, RTP over DCCP, DTLS over DCCP.Phelan - assumes we want to accept the drafts for the new milestones,
etc.
Allison - you would need buy-in from the ADs/IAB for mobility.
Eggert - this is the output of Vancouver
Allison - it would need to be socialized
EKR - I like the charter. Mobility seems appropriate. I'd
love to work on DTLS over DCCP, but can't do it myself
so if people don't want to, that's fine too.
Allison - DTLS would be good to work on.
Sally - I like the charter.
Eggert - Do we have consensus from the WGs that they'd like
to work on these items and send comments, etc. That's been
a problem lately.
Phelan - should we hum on DTLS?
EKR - we really need someone who knows DCCP better
Phelan - I'm willing to work on it.
Eggert - let's take the criteria to the mailing list
Eggert - we first need to agree that the areas are interesting and
then we can adopt drafts as appropriate
6. draft-perkins-dccp-rtp (Colin Perkins)
See slides. I'm mainly noting discussion:
This draft does:
1. Framing mechanism for RTP over DCCP
2. Extensions to SDP to negotiate RTP over DCCP.
Framing:
Instead of using multiple ports, just use one DCCP flow and
demux by payload type.
EKR - why not do this in UDP
CSP - You could.
Casner - One reason for separate ports is for multicast, which
isn't an issue with DCCP, which is unicast.
Eggert - we don't have a NAT traversal story
CSP - RTCP interval and congestion control interaction
Mankin and CSP - it's a general DCCP issue.
Phelan - the problem is that there may be a lot of sessions per
DCCP so the nominal bandwidth may be confused. One issue is
asymmetric lines.
CSP - this is a generic problem for RTP over any congestion
controlled transport.
Phelan - should all profiles of RTP work ok with DCCP.
CSP - yes, except, of course, the congestion controlled one.
Signalling:
Use SDP. See slides again.
CSP - should we define standard service codes.
Phelan - this wouldn't exclude other service codes being
used?
CSP - No
Eddie, Phelan, and others - OK.
Accept as WG draft?
Eggert - this depends on the charter.
Phelan - need to coordinate with AVT?
CSP - pass it by for comment.
Eggert - common last call...
Craig White - has AVT seen this document?
CSP - not yet, but I am happy to.
White - there's some stuff here that seems to have fallen by
the wayside. Do you think it will be ok with AVT?
CSP - the multiplexing, at least, seems to go over well.
AVT may not want congestion control as much <laughs>.
Eggert - roll congestion control for media into TFRC media
draft.
7. draft-kohler-dccp-mobility-01 (Pasi Sarolahti)
Slides available.
Eggert - there are network protocols (e.g., HIP) that will provide
mobility for all protocols. Do we need to do mobility at L4.
Discuss with INT ADs.
PS - It's lightweight.
Eggert - but you need to redo it for each protocol.
PS - HIP may not happen
Eggert - SHIM6, MULTI6, ...
PS - alternative is to tear down the connection. Doesn't compete
with Mobile IP.
CSP - Is SCTP's mobility now considered a mistake?
PS - Nice use case is to have SIP on SCTP and then this on DCCP.
Mankin - Analogous to SCTP. We'll hear about use cases later.
A lot of things on the net don't work well if you change a
connection--e.g., NAT, v4/v6 transition. So, this may be
dangerous.
PS - Should work with NAT
Mankin - Why?
PS - in rest of presentation.
Kohler (via CSP) - this does work with NAT
Phelan - I'm having experience with a telco who wants SIP over
SCTP. But they won't use multihoming.
Michael Tuexen - Add-IP in SCTP isn't for mobility but for
long-lived associations, e.g., a year.
PS - it's a robustness feature (like multihoming) rather than
mobility.
Kohler (via CSP) - I would change this to multiple addresses
rather than mobility.
PS - Should this be chartered?
Magnus Westerland - Does this gain any advantage? Isn't it more
important for DCCP to work on cong control, deployment, etc.
Do we have a customer for this feature?
PS - There is skepticism about this. No clear incentive.
Mankin - I'm changing my position. Motivation wasn't presented
right. This is your NAT traversal story. Your equivalent of
ICE. I would call it "GenCon"
MW - You have to be careful how you use this with multiple
connections. Changing your path creates problems (also exist
with ICE).
CSP/Kohler - this may be useful but I don't think it removes
the need for ICE over DCCP.
Phelan - This is more than reliability than mobility, esp.
in the telephony world)
End of charter -- anyone want to work on DTLS? Apparently not...
8. draft-ietf-dccp-tfrc-voip-05
Changed the name to TFRC for small packets
MW - byte drop mode pushes TCP towards smaller packets.
Floyd - only true with packet drop rates above 15%. This is
good for TCP because it makes it less likely to drop SYNs,
ACKs, etc. Good for VoIP. Just means that things aren't
totally fair (in favor of the VoIP traffic).
CSP - Errata for TFRC? Worthwhile submitting an update
with the errata.
Floyd - a little more work but the better thing to do. I'll
get on it.
White - Thanks for your explanations. You said we don't
know what internet drops really are. In the core, congestion
isn't normal, so you wouldn't expect to see high drop rates
except for link cuts. What does the response curve look
like under recovery.
Floyd - you mean a transient event. If you're going to tell
people to deploy it only in certain scenarios then how
does the user know. This is end-to-end cong. control.
White - this is a last mile issue rather than the core.
What behavior would we see under that scenario.
Floyd - I'll think about that.
Floyd - Faster restart draft now available. Fast start
after idle. Be more aggressive. Restart up to 8 small
packets (4 kb). Needs someone to do some experiments
and simulations. Eddie and I will eventually work
on that...
9. Eggert
We've dropped the ball on TFRC maintenance. It will be
on the charter when we send it to the list.
10. Mankin
IANA wants an expert reviewer for checking DCCP port
requests. Volunteers.
Eddie - assumes its him.
Mankin - they expect fast turnaround. A day or so.
11. Floyd
Thanks to Allison for getting us through Auth48, etc.
Done.
--
Lars Eggert NEC Network Laboratories
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
