|
can we know more on what perkins says below:
>Colin Perkins on experiences with
interactive video using TFRC. He described joint work
> with ISI funded by NSF. His experience was of using TFRC in user space, and > some open issues that may impact implementation of DCCP CC methods. This > follows the TFRC profile in AVT. This is approx 8 Mbps of video, and packet > spacing is hard in user-space, which is an implementation issue. The end > result is that stability is hard with RTTs of less than 10 or 20 ms. It gets > more stable at larger RTTs. thanks,
saverio
On 7/17/06, Gorry Fairhurst <gorry@xxxxxxxxxxxxxx> wrote:
> Dear WG, > > Here is the first take at the minutes, thank you to the minute takers, and > Jabber scribe. Please send any comments, or updates to the WG Chairs, and > we'll fix them. > > We like to express our thanks to Pasi & Eddie for agreeing to postpone their > talk to the next IETF meeting (when we ran short of time) - They have an > updated individual draft (and their slides are included in the proceedings). > > Best wishes, > > Gorry & Tom > > ----- > > > Datagram Congestion Control Protocol (DCCP) > WG WG Chairs: Thomas Phelan <tphelan@xxxxxxxxxxxx> Gorry Fairhurst > <gorry@xxxxxxxxxxxxxx> > Note-takers: Haitham Cruickshank & Sally Floyd > > 1. Agenda Bashing > > > 2. Document Status > > Tom Phelan introduced the work items and status. The Small-Packet (SP) > Variant of TFRV was with the WG Chairs, who needed to prepare a write-up for > the IESG. > > This was followed by a review of the new Charter by Gorry Fairhurst that > highlighted changes since the presentation at the last IETF. > > Gorry: Are there any comments on the Charter? Sally Floyd said charter was > good. > > Tom Phelan noted that an Errata had been filed for the DCCP spec. This had > not received negative comments when posted to the DCCP list. It had just > been sent to the RFC Editor and implementers should note this when reading > the DCCP Spec. > > > 3. Active Drafts > > 3a Faster Restart Sally Floyd presented an update on > <draft-ietf-dccp-tfrc-faster-restart> on behalf of Eddie Kohler (who was > present via Jabber). Describing an enhancement to TFRC (also CCID3) after an > Idle period. This is slightly more aggressive than TCP would currently be. > Arjuna and Vlad had made comments to the list about various issues such as > the impact of the idle period during slow-start and issues of sending lower > packet rates at the start of an idle period. Text relating to both of these > had been added to the latest rev of the draft. The reported receive rate > now also notes the number of packets that were received. There are some > options, and there are issues still to be addressed. > > Eddie: Clarified that the reporting in an idle period was actually not one > packet per RTT, but actually one packet per idle period, which is worse. > > Tom: What do the words "draft draft draft" mean in the draft? Sally: These > were added by Eddie, these bits are work in progress. Further inputs are > being looked for. > > 3a1 Issues with faster-restart. Gorry presented some simulation results of > TFRC and Faster Restart on behalf of Arjuna Sathiaseelan (who was present > via Jabber). There were some issues with the 2.30 release of ns2; he had > worked on a fix (Sally also has a new fix). These now need to be compared. > > Some simulations are needed. Sally does not want to do this, Eddie may? > After that the draft will need to be updated. > > Tom: There is a milestone for Dec 2006 for Faster Restart, is this > reasonable? > > Gorry: Arjuna has volunteered. Sally & Gorry: This seems reasonable, unless > we find something unexpected in the simulation results. > > 3b User Guide Tom Phelan presented an update on the User Guide, > <draft-ietf-dccp-user-guide>, and media guide <draft-ietf-dccp-tfrc-media>. > The user guide needs a re-write and we need to work on this, primarily on > implementation experience. TFRC media is also awaiting practical experience. > > Gorry: The TFRC media Guide is first on our list of chartred items, giving > experience with UDP, TFRC. Tom: Yes. Gorry: What do we need in the User > Guide? Tom: We need inputs, based on the API needs, etc. Gorry: I would also > like to see input on NAT traversal and DCCP Service Codes; how to actually > use DCCP. Tom: We need both inputs from the implementers and this WG. Should > we trawl the list to look for content? Collin Perkins: Yes, we need a > mixture of implementor inputs and how the WG sess the advanced features > being used. I expect this to iterate. We can not write this today. Tom: OK. > Gorry: That sounds like the right way to go. Tom: I can do a new rev by the > next meeting. Gorry: This is also something we need feedback from the group > to get the correct section names set out. Tom: We also need people to look > at the streaming models in the media guide. > > > 3c Implementation feedback & issues > > 3c1 Linux DCCP Implementor Feedback from Ian McDonald. Gorry Fairhurst > presented on behalf of Ian McDonald (participating via Jabber). Ian had been > working on DCCP on Linux 2.1.68rc1. There is incremental improvement, but no > TFRC-SP support yet. Testing had been done with netem, and some live tests. > Still much work needed to meet the spec, and there are known issues on > performance. There is still a problem with high-speed links. > > Tom: Where did the limit come from? It says on the slide, high-speed low > latency, what were the conditions? Ian: The link is 100 Mbps. It breaks when > there is a router in the path. Eddie: What does "breaks" mean? Ian: It > re-synchs. Tom: Could we send a description to the list? Ian: This a > performance problem, not a protocol problem. Gorry: We should encourage such > implementation, and the Chairs and WG would like to know what is happening > and help were they can. > > 3c2 Linux DCCP Implementor Feedback from Andrea Bittau This was presented by > Mark Handley. CCID2 and CCID3 have been implemented. There are > implementation issues (only long sequence numbers are supported). ECN is > supported but not yet linked to IP. Feature negotiation works, but the API > needs to be hooked up. For CCID2, the timer measurements are in clock-ticks, > with resultant problems for low delay links (which would give a zero time). > ACK Ratios not yet supported. > > Aaron: Is there a reason for the timer resolution to be in Hz? Mark: Not > sure, need to ask Andrea. > > The protocol uses a socket type of SOCK_DCCP, which may not be the right > thing to do, and probably should be more general. SOCK_Stream is probably > not also right. What should it be changed to? > > Colin: What is SOCK_Stream defined as? Mark: The manual says this is a > byte-stream. Aaron: There are other options for the name of the socket: > SOCK_unreliable_stream; SOCK_Congestion_controlled, etc. Eddie: The service > code was extensively discussed on the Linux list. Ian: My implementation has > a socket buffer, with a memory limit, but this is not merged yet. Eddie: > Some people wanted the service code to be optional, and he argued against. A > discussion followed on the size of the socket buffer queue. There was > agreement that a large queue is not needed, but a queue of at least one > packet is probably a good idea. The API to the service code also needs to be > clarified. It currently has no buffer for input to DCCP. > > Colin: My feeling is that there should not be a big buffer here. Mark: > Right, but I think it should have a queue of at least one, you do not want > to have to go to user-land each time an ACK arrives. You probably should > configure this. Colin: Our experience with interactive video is that we > would like it to be small. Mark: Yes, but there are issues in waking up the > application too often. We need some sensible approach to get good > performance. > > Aaron: Are there two implementations, or one? Mark: These are the same > implementation in Linux. > > Feature negotiation works, but the way to get the result of the negotiation > is not yet available. There are lots of patches expected to come through in > .19 release. He expects a full stable release mid of next year. > > 3c3 Implementor Feedback of TFRC from Colin Perkins Colin Perkins presented > on experiences with interactive video using TFRC. He described joint work > with ISI funded by NSF. His experience was of using TFRC in user space, and > some open issues that may impact implementation of DCCP CC methods. This > follows the TFRC profile in AVT. This is approx 8 Mbps of video, and packet > spacing is hard in user-space, which is an implementation issue. The end > result is that stability is hard with RTTs of less than 10 or 20 ms. It gets > more stable at larger RTTs. > > Mark: I have a student is working on a window based TFRC, but the work is > not yet ready to show, but it does work quite well. Jabber: More accurate > timing might help. Would it work better for low latency links if you used a > smaller timer tick? Old kernels used 10ms, newer can use 1 or 4 ms. Colin: > It certainly helps in MacOS which gets more accurate timing and is more > stable. Jabber: You can set the timer ticks to whatever you want with the > new kernel. Colin: OK. This also impacts feedback timing, which can be an > issue. > > Mark: This implementation is in user space. How many of these problems go > away with a kernel-based implementation? Colin: Depends on timing, its still > involves application activity. Mark: It must be easier than waking the > application up for everything. Matt Mathis: Did you look at the sensitivity > to other things happening on the system? Colin: Systems were more or less > idle. Matt: There can still be a lot of background chatter. Jabber: We > believe these problems will go away if we have a kernel implementation. > Colin: Agreed. Jabber: Others have tried timers in microseconds, and let you > track the RTT is microseconds. It works fine there. Eddie: What is an > acceptable buffer size here? Colin: One video frame. > > Continues presentation saying adaptation is easier at a higher frame rate. A > better codec would help, and we need to understand the quality that we > get. Kernel DCCP would help. Not sure if we understand this problem good > enough to get issues sorted for the media guide. > > Gorry: How long until we have the information for the media guide to be > updated? Colin: Some initial advice could be available in about 1 year. > There are a lot of open issues. These are mainly are codec issues and do not > relate to DCCP. Gorry: We need to understand what we can do, and write this > based on what we have. Colin: Yes, and accept that the media guide may need > to be updated from time to time. Eddie: Some of the problems might become > easier with a kernel implementation. I do not think that the media > guide should be based on user-level implementations, when it is not clear > which issues come from this and which do not. Colin: Sure, but it is the > best we have got. ?: The experience may also vary depending on which level > the implementation is at. Colin: We do need to do the same sort of > experiments in the kernel. Mark: We have talked off and on about using the > TFRC rate as a reference rate (rather than a strict limit), and allowing > the CCID3 sender to go above and below that rate. What is your view? Colin: > It may. Mark: You could allow +/- 20% of the reference rate, keeping the > application in control. The CC would only impact when it changes beyond > these bounds. This helps change the time-scales. There are lots of > unanswered questions here. Tom: Most of these are interactive issues. The > media guide (currently) deals more with streaming media, rather than > with interactive media. Do you have streaming experience? Colin: Not really > in these tests. Tom: Can we write-up streaming and just say interactive is > crazy in the media guide? Gorry: No, but we could continue the split the > advice into conversational and streaming and give different advice in each. > > > 4. Potential New WG Items > > 4a DCCP CCID4: TFRC with Small Packets Sally Floyd presented on < > draft-floyd-ccid4-00>. There was one correction to a slide, concerning a > label that should have been "max sending rate" (not min sending rate). The > I-D is an individual I-D, but intended for WG adoption. > > ?: Does CCID4 mean there is a maximum sending rate? Sally: Yes, 100 pps. > > Mark: Does TFRC-SP have oscillations around the boundary of switching the > method for reporting loss event rates at the two-RTT boundary? Can a > discontinuity occur, where the sender jumps in rate to a higher threshold > because of the loss interval? Sally: We looked, a little bit. Mark: If there > were losses in bursts of 10 packets, then if these fell in a bad interval > there could be really severe oscillation. Sally: I will go back to TFRC-SP > and check this. I think 2 loss intervals should be OK. > > Gorry noted we need some people to read this new draft. > > > 4b DTLS over DCCP Tom Phelan presented on <draft-phelan-dccp-dtls-00>, about > transport layer encryption. DTLS could potentially use the DCCP handshake to > carry the DTLS setup. He described clarifications for PMTUD in DTLS will be > constrained by DCCP PMTUD method. Gorry said the draft should say which > service code should be used. He also spoke about what would be the impact of > changes to DTLS. > > Eric Rescorla: A new version of DTLS should automatically negotiate, so > changes in version should not be a problem. Tom: I will add text on this > to say DTLS/DCCP will track updates to DTLS. > > Mark: This question of service codes is a good question. I guess I view > DTLS as a content transfer encoding rather than a content type, and service > codes describe content type. At first I thought it should stay the same as > the port and that it should be the same even if the content is encrypted. We > need to decide. Gorry: I agree, this is a crucial point for deciding. > Firewalls may have a view on the content being carried by DTLS rather than > the content. Mark: There is no obvious right answer. We need to decide. > Tom: We should take this question to the list. If we set the code to say a > flow is video, this may be more useful than saying it is unknown encrypted > content. Collin: My thought was the service code reflected the server, but I > can see the other argument too. I do not like the current proposal though. > We need to decide. Eric: What people do in TCP is a separate port for each > application running over TLS, or you use the same port and have a > de-multiplexing. > > Again, the WG is looking for some more comment from the list, and then we > can see about making this a WG item against our milestone. > > > 4c TFRCbis (update to RFC3448) Sally Floyd presented on > <draft-floyd-rfc3448bis-00>. This is a maintenance update that was requested > at the last IETF, to encompass the Errata, larger initial window, etc. > > The WG was asked if they wished this to proceed as a WG item. A hum > confirmed there was support for adopting this as a WG item. There was no hum > against. The next rev of the I-D will therefore be accepted by the Chairs as > a WG draft. Gorry noted we still do need some people to read this new draft. > > > 4d RTP over DCCP Colin Perkins presented on <draft-perkins-dccp-rtp-02>. > He spoke about nominal bandwidth, RTCP feedback, and the implications of > DCCP capacity changes. There was still more work to do. > > Mark: Suppose you have a case where your codec can adapt rate by an order of > magnitude. What do you choose as the nominal bandwidth? Colin: To be safe, > you have to use the bottom range of bandwidth. Trying to make the RTCP > reactive is going to be far too complicates. You could also renegotiate. We > should not duplicate things in the user and media guide. There are some more > issues to be included in the next draft. A December milestone should be OK. > > Gorry: This has been tabled at two IETFs now, and is in response to a > charter milestone. Who read either of these two versions? - Some. A hum > confirmed there was support for adopting this as a WG item. There was no hum > against. The next rev of the I-D will be accepted by the Chairs as a WG > draft. > > > 4e DCCP Mobility The authors had updated the I-D > <draft-kohler-dccp-mobility>. This is an individual draft (see notes on > Charter revision). It was agreed to postpone this discussion to the next > IETF, where there would be more time. > > --- > > > > |
