Hi, I've uploaded a draft agenda for Dallas into the IETF system; see http://www3.ietf.org/proceedings/06mar/agenda/dccp.txt Please send/additions corrections. Lars -- -- Lars Eggert NEC Network Laboratories
I sent in the revised version of draft-ietf-dccp-tfrc-voip-05.txt this morning, in response to feedback from Working Group Last Call. A local copy is available at: http://www.icir.org/floyd/papers/draft-ietf-dccp-tfrc-voip-05.txt http://www.icir.org/floyd/papers/draft-ietf-dccp-tfrc-voip-05.ps Figures for the graphs are available at: http://www.icir.org/tfrc/voipsims-05/voipimages-05.ps http://www.icir.org/tfrc/voipsims-05/voipimages-05.pdf The list of changes is appended below. The most interesting additions are the last two tables in Section 7.3. "These two sets of simulations illustrate the dangers of a widespread deployment of TFRC-SP in an environment where small packets are less likely to be dropped than large ones." - Sally http://www.icir.org/floyd/ Changes from draft-ietf-dccp-tfrc-voip-04.txt: * Added tables showing the response function for TCP, TFRC, and TFRC-SP, for a range of packet sizes, for both packet and byte drop rates. In response to feedback from Magnus Westerlund. * Along with response function, added that TCP's sending rate varies linearly with packet size. From a suggestion by Magnus Westerlund. * Added a sentence saying that TCP has a range of sender(Continue reading)
Hi, On Mar 1, 2006, at 20:10, Sally Floyd wrote: > I sent in the revised version of draft-ietf-dccp-tfrc-voip-05.txt > this morning, in response to feedback from Working Group Last Call. if you've had some comments about -04 during WGLC, please check if you're happy with -05. Otherwise, please yell. (Everyone else, please also check -05, but you should have really spoken up by now.) We'll officially end WGLC on Monday, pending negative feedback, and forward this draft to the IESG for approval. Thanks, Lars -- -- Lars Eggert NEC Network Laboratories
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Datagram Congestion Control Protocol Working Group of the IETF. Title : TCP Friendly Rate Control (TFRC): the Small-Packet (SP) Variant Author(s) : S. Floyd, E. Kohler Filename : draft-ietf-dccp-tfrc-voip-05.txt,.ps Pages : 41 Date : 2006-3-3 This document proposes a mechanism for further experimentation, but not for widespread deployment at this time in the global Internet. TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment [RFC 3448]. TFRC was intended for applications that use a fixed packet size, and was designed to be reasonably fair when competing for bandwidth with TCP connections using the same packet size. This document proposes TFRC-SP, a Small-Packet (SP) variant of TFRC, that is designed for applications that send small packets. The design goal for TFRC-SP is to achieve the same bandwidth in bps as a TCP flow using packets of up to 1500 bytes. TFRC-SP enforces a Min Interval of 10 ms between data packets, to prevent a single flow from sending small packets arbitrarily frequently. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dccp-tfrc-voip-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce(Continue reading)
On 3/7/06, John S. Estabrook <jestabro <at> ncsa.uiuc.edu> wrote: > > Connie, 2.0.2 is the recommended version, which addresses several bugs in > 2.0.1; the patch for 2.0.2, if you're refering to the one mentionied at > the bottom of the iperf page, was submitted but is not necessary---it's a > feature addition (re DCCP), not a bug fix. > I wondered who had also written an iperf patch for DCCP besides me and I see that my code has been posted up there(Continue reading)Just a note for those looking in future - the iperf works for Linux 2.6.14 but not on the latest development kernels. I will work on fixing this at some point but if anybody feels brave I think it is because of the introduction of service codes. It is also worth adding multiple CCID support as well I believe... I also intend to start merging some of the changes into the iperf codebase over time (probably a long time with my current workload!). Also this code was originally written by others and I've just tidied it up a little bit. Ian -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand
Hi, On Mar 1, 2006, at 23:41, Lars Eggert wrote: > On Mar 1, 2006, at 20:10, Sally Floyd wrote: >> I sent in the revised version of draft-ietf-dccp-tfrc-voip-05.txt >> this morning, in response to feedback from Working Group Last Call. > > if you've had some comments about -04 during WGLC, please check if > you're happy with -05. Otherwise, please yell. (Everyone else, > please also check -05, but you should have really spoken up by now.) > > We'll officially end WGLC on Monday, pending negative feedback, and > forward this draft to the IESG for approval. we have not seen any further comments and thus assume that draft-(Continue reading)ietf- dccp-tfrc-voip-05 has passed WGLC. DCCP has been a testcase for the PROTO process in the past. We've dropped the ball a bit on this during the handover from Aaron to Tom and me, but I'd like to propose that we start using PROTO again, starting with this ID. Tom has agreed to be the document shepherd. Lars PS: Good news from the RFC editor - the spec, both CCIDs and the problem statement have just hit AUTH48. -- -- Lars Eggert NEC Network Laboratories
On 7 Mar 2006, at 09:46, Lars Eggert wrote:
...
> PS: Good news from the RFC editor - the spec, both CCIDs and the
> problem statement have just hit AUTH48.
One minor nit I noticed while updating the RTP-over-DCCP draft, which
it might be possible to fix in AUTH48. Section 8.1.2 states:
SC= Indicates a decimal Service Code. The octothorp is
followed
by any number of decimal digits, which specify the Service
Code. Values above 4294967294 are illegal.
but there is no octothorp in the syntax. Is the intent to specify
"SC=#123456" or "SC=123456"?
Colin
I actually noticed that a week or two ago -- it should say "The equals sign is followed..." Thanks as usual for the close read :) E Colin Perkins wrote: > On 7 Mar 2006, at 09:46, Lars Eggert wrote: > ... >> PS: Good news from the RFC editor - the spec, both CCIDs and the >> problem statement have just hit AUTH48. > > One minor nit I noticed while updating the RTP-over-DCCP draft, which it > might be possible to fix in AUTH48. Section 8.1.2 states: > > SC= Indicates a decimal Service Code. The octothorp is followed > by any number of decimal digits, which specify the Service > Code. Values above 4294967294 are illegal. > > but there is no octothorp in the syntax. Is the intent to specify > "SC=#123456" or "SC=123456"? > > Colin >
A new version of the RTP-over-DCCP draft is available. Changes include: - Extensive editorial changes and clarifications - Clarify that the DCCP connection remains open for the duration of the RTP session. - Update discussion of multiplexed RTP and RTCP in section 4.3 - Clarify signalling of the RTCP port. - Align the syntax of the "a=dccp-service-code:" SDP attribute with that defined in section 8.1.2 of the DCCP specification. - Register standard service codes for RTP sessions. - In section 4.5, explicitly document which profiles can be used with DCCP. - In section 4.1, mandate that partial checksums cover the RTP and DCCP headers (SHOULD -> MUST) - Rewrite normative language in section 4.4 I'll be discussing this in Dallas, but comments to the list would also be appreciated. Colin Begin forwarded message: > From: Internet-Drafts <at> ietf.org > Date: 9 March 2006 20:50:02 GMT > To: i-d-announce <at> ietf.org > Subject: I-D ACTION:draft-perkins-dccp-rtp-01.txt > Reply-To: internet-drafts <at> ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >(Continue reading)
Dear all, I am performing experiments with VBR rate controlled video over TFRC (in ns-2.28). [I have also noticed the VoIP initiative in DCCP, to cope with silent periods etc., so I believe that my findings could be "compliant" to the motivation behind that initiative.] My results with VBR video (using I- and P-frames) shows that it is very hard for the application to grab available capacity, if the TFRC send queue is kept short to minimize overall latency. When this queue is short, it is often drained completely, while transmitting the smaller P-frames. Thus, the actual sending rate is lower than the allowed sending rate, and the TFRC is "trapped" in the slowstart phase, often causing a step-down of actual max rate to the previous measured sending rate. It can actually force "oscillations" in the algorithm (measurement period is smaller than the Group of Pictures (GOP), thus some measurements contain only P-frames, while others contain also the larger I-frame). If the sending queue is allowed to become larger, the TFRC rate is somewhat smoother, but still the results are not satisfactory. Can someone reply and answer if my findings are just "old news", and only reflects defects that the new "VoIP" flavoured TFRC will "repair"? Or, is it possible to e.g. tell TFRC to do more seldom rate measurements so that to avoid oscillations due to the GOP periodicity? Best regards Arne Lie NTNU, Norway(Continue reading)
RSS Feed4 | |
|---|---|
1 | |
2 | |
1 | |
2 | |
4 | |
13 | |
1 | |
35 | |
35 | |
12 | |
18 | |
11 | |
49 | |
9 | |
27 | |
7 | |
13 | |
12 | |
28 | |
2 | |
10 | |
23 | |
4 | |
44 | |
24 | |
5 | |
2 | |
22 | |
14 | |
18 | |
12 | |
20 | |
3 | |
1 | |
15 | |
18 | |
10 | |
27 | |
11 | |
4 | |
9 | |
14 | |
9 | |
33 | |
66 | |
25 | |
49 | |
30 | |
35 | |
13 | |
36 | |
48 | |
36 | |
28 | |
16 | |
106 | |
31 | |
27 | |
16 | |
47 | |
48 | |
54 | |
29 | |
26 | |
21 | |
20 | |
14 | |
37 | |
8 |
