TFRC Faster Restart implementation for Linux DCCP

TFRC Faster Restart implementation for Linux DCCP

[Ian McDonald]

Folks,

At the suggestion of my PhD supervisor, I am considering implementing
TFRC faster restart for the Linux version of DCCP.

From my reading of the correspondence it would seem to me that the
testing was done in ns2 and not in the Linux kernel. If this is not
correct, or you know of any implementations, can you tell me so I
don't reinvent the wheel!

Thanks,

Ian
-- 
Web: http://wand.net.nz/~iam4/
Blog: http://iansblog.jandi.co.nz
WAND Network Research Group

RE: [dccp] TFRC Faster Restart implementation for Linux DCCP

[Arjuna Sathiaseelan]

From the simulation point of view, we have been constantly revising the code
to accommodate the latest revisions of the draft. We at UoA havent
implemented the FR algorithm yet.

Arjuna


-----Original Message-----
From: Ian McDonald [mailto:ian.mcdonald@jandi.co.nz] 
Sent: 16 July 2007 05:32
To: Arjuna Sathiaseelan; Eddie Kohler
Cc: Gorry Fairhurst; Gerrit Renker; DCCP mailing list; Richard Nelson; DCCP
Mailing List
Subject: [dccp] TFRC Faster Restart implementation for Linux DCCP

Folks,

At the suggestion of my PhD supervisor, I am considering implementing
TFRC faster restart for the Linux version of DCCP.

From my reading of the correspondence it would seem to me that the
testing was done in ns2 and not in the Linux kernel. If this is not
correct, or you know of any implementations, can you tell me so I
don't reinvent the wheel!

Thanks,

Ian
-- 
Web: http://wand.net.nz/~iam4/
Blog: http://iansblog.jandi.co.nz
WAND Network Research Group

Re: TFRC Faster Restart implementation for Linux DCCP

[Gerrit Renker]

You didn't write whether you intend this as Linux mainline work.

I am not aware of anyone else working on this so far. However, it reopens a big can
of worms for the CCID3 code in the kernel: much in Faster Restart depends on the 
rfc3448bis changes to computing the sending rate and determining idle/application-limited
times. 
The algorithm keeps changing in each new revision of the rfc3448bis draft, which probably
means that when you've just finished your work, you can start from scratch again.

Thus my suggestion is - if you want to do this community-wise - to do this as part/sub-branch
of the testing tree. There is still a lot of space for further branches, and it is not clear
when all this will stabilise.

Thoughts?

Quoting Ian McDonald:
|  Folks,
|  
|  At the suggestion of my PhD supervisor, I am considering implementing
|  TFRC faster restart for the Linux version of DCCP.
|  
|  From my reading of the correspondence it would seem to me that the
|  testing was done in ns2 and not in the Linux kernel. If this is not
|  correct, or you know of any implementations, can you tell me so I
|  don't reinvent the wheel!
|  
|  Thanks,
|  
|  Ian

Re: TFRC Faster Restart implementation for Linux DCCP

[Ian McDonald]

Gerrit,

My aim for this is to eventually hit mainline.

I agree that the spec has changed quite significantly and may yet
change again. However I'm in need of more data for my thesis and both
Richard (my supervisor) and Gorry have suggested I look at faster
restart for my ideas. We (Lulea/Wand/Arnaldo) did the initial
implementation of DCCP while the spec was changing so it is kind of
familiar.

I want to be able to keep the code in one tree and there is plenty of
examples of non-RFC compliant code in the Linux kernel for
experimental protocols (e.g. DCCP, SCTP) while they stabilise and
shortly afterwards. My idea is that you can choose whether to use TFRC
faster restart or not. Given how TCP handle extensions I think the
best way for this is a sysctl as can turn it on or off system wide.
The default, initially, should be off. The other alternative is to
enable it via a socket option as TCP Nagle does.

I will be using your git-tree as my development base and once I get it
coded I'd be greatly pleased if you can put it in the tree somehow.

Any comments gratefully received.

Ian

On 7/17/07, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> You didn't write whether you intend this as Linux mainline work.
>
> I am not aware of anyone else working on this so far. However, it reopens a big can
> of worms for the CCID3 code in the kernel: much in Faster Restart depends on the
> rfc3448bis changes to computing the sending rate and determining idle/application-limited
> times.
> The algorithm keeps changing in each new revision of the rfc3448bis draft, which probably
> means that when you've just finished your work, you can start from scratch again.
>
> Thus my suggestion is - if you want to do this community-wise - to do this as part/sub-branch
> of the testing tree. There is still a lot of space for further branches, and it is not clear
> when all this will stabilise.
>
> Thoughts?
>
> Quoting Ian McDonald:
> |  Folks,
> |
> |  At the suggestion of my PhD supervisor, I am considering implementing
> |  TFRC faster restart for the Linux version of DCCP.
> |
> |  From my reading of the correspondence it would seem to me that the
> |  testing was done in ns2 and not in the Linux kernel. If this is not
> |  correct, or you know of any implementations, can you tell me so I
> |  don't reinvent the wheel!
> |
> |  Thanks,
> |
> |  Ian
-- 
Web: http://wand.net.nz/~iam4/
Blog: http://iansblog.jandi.co.nz
WAND Network Research Group

Re: TFRC Faster Restart implementation for Linux DCCP

[Gerrit Renker]

|  Given how TCP handle extensions I think the
|  best way for this is a sysctl as can turn it on or off system wide.
|  The default, initially, should be off. The other alternative is to
|  enable it via a socket option as TCP Nagle does.
Could use a module parameter to the CCID3 module to enable it.

|  
|  I will be using your git-tree as my development base and once I get it
|  coded I'd be greatly pleased if you can put it in the tree somehow.
Yes sure - that is what the tree is there for.

Re: TFRC Faster Restart implementation for Linux DCCP

[Ian McDonald]

On 7/18/07, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> |  Given how TCP handle extensions I think the
> |  best way for this is a sysctl as can turn it on or off system wide.
> |  The default, initially, should be off. The other alternative is to
> |  enable it via a socket option as TCP Nagle does.
> Could use a module parameter to the CCID3 module to enable it.

I've decided to go with a socket option for now but this trivial to
alter the code around it.
>
> |
> |  I will be using your git-tree as my development base and once I get it
> |  coded I'd be greatly pleased if you can put it in the tree somehow.
> Yes sure - that is what the tree is there for.

Thanks.
-- 
Web1: http://wand.net.nz/~iam4/
Web2: http://www.jandi.co.nz
Blog: http://iansblog.jandi.co.nz

Re: TFRC Faster Restart implementation for Linux DCCP

[Gerrit Renker]

Quoting Ian McDonald:
|  > |  Given how TCP handle extensions I think the
|  > |  best way for this is a sysctl as can turn it on or off system wide.
|  > |  The default, initially, should be off. The other alternative is to
|  > |  enable it via a socket option as TCP Nagle does.
|  > Could use a module parameter to the CCID3 module to enable it.
|  
|  I've decided to go with a socket option for now but this trivial to
|  alter the code around it.
I think this is even better than a module option, since faster restart will
also affect CCID4. The problem with module options is that unloading does not
really work.

A while ago I noticed that DCCP does not support the SO_KEEPALIVE option, and the 
ping probes of FR somewhat link up with this. Maybe something similar to TCP_KEEPCNT, 
TCP_KEEPIDLE, TCP_KEEPINTVL is possible here?

There is an issue with the ping probes, will write up in a separate email.

Re: TFRC Faster Restart implementation for Linux DCCP

[Ian McDonald]

On 7/26/07, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> There is an issue with the ping probes, will write up in a separate email.
>
I'm not intending to implement ping probes as per IETF mailing list.

Ian
-- 
Web1: http://wand.net.nz/~iam4/
Web2: http://www.jandi.co.nz
Blog: http://iansblog.jandi.co.nz

Re: TFRC Faster Restart implementation for Linux DCCP

[Gerrit Renker]

|  > There is an issue with the ping probes, will write up in a separate email.
|  >
|  I'm not intending to implement ping probes as per IETF mailing list.
I am just about to catch up with the results from Monday ... it seems the authors
are going to make the ping probes optional anyway.
http://www1.ietf.org/mail-archive/web/dccp/current/msg02478.html

The problem that I found with the ping probes is that they need to be sent at a
rate of max(t_ipi, 4*R). With small RTTs, this would mean bursts of 3..10 ping
packets per timer tick ... which is quite a lot for an `idle' connection.