Lars Eggert | 1 Mar 15:18 2006
Picon

draft agenda for Dallas

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

Attachment (smime.p7s): application/pkcs7-signature, 4981 bytes
Sally Floyd | 1 Mar 20:10 2006

draft-ietf-dccp-tfrc-voip-05.txt

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)

Lars Eggert | 1 Mar 23:41 2006
Picon

Re: draft-ietf-dccp-tfrc-voip-05.txt

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

Attachment (smime.p7s): application/pkcs7-signature, 4981 bytes
Internet-Drafts | 3 Mar 21:50 2006
Picon

I-D ACTION:draft-ietf-dccp-tfrc-voip-05.txt

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)

Ian McDonald | 6 Mar 21:14 2006
Picon

DCCP with iperf was Re: Question on iperf versions

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 :-)

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
(Continue reading)

Lars Eggert | 7 Mar 10:46 2006
Picon

Re: draft-ietf-dccp-tfrc-voip-05.txt

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-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

(Continue reading)

Colin Perkins | 7 Mar 10:58 2006

Re: spec nits

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

Eddie Kohler | 7 Mar 18:56 2006

Re: Re: spec nits

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
> 

Colin Perkins | 10 Mar 18:31 2006

Fwd: I-D ACTION:draft-perkins-dccp-rtp-01.txt

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)

Arne Lie | 13 Mar 15:34 2006
Picon
Picon

VBR rate controlled video over TFRC: Observations

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)


Gmane