[PATCH 0/6] DCCP: Implement TFRC Faster Restart

[PATCH 0/6] DCCP: Implement TFRC Faster Restart

[Ian McDonald]

This patch set implements TFRC Faster Restart as per current draft.

Patche can also be found at:
http://wand.net.nz/~iam4/dccp/patches24/
(although do not apply patch 7)

The faster restart implementation was based on 
draft-ietf-dccp-tfrc-faster-restart-03.txt.

The version of DCCP CCID3 in Gerrit's tree used as the base is (mostly) 
draft-floyd-rfc3448bis-00.txt where the faster restart Internet Draft 
specifies the use of draft-ietf-dccp-rfc3448bis-02.txt.

We did not implement all of the Internet Draft for faster restart as it was 
either not required, or the base DCCP did not support the features required.

In particular the following features are missing:

    * keep alive pings as per section 3.1. It has been proposed at IETF 69 to 
remove these.
    * the use of X_recv_set as per section 3.2. We use X_recv instead as 
X_recv_set is not part of rfc3448bis-00.txt
    * Interpolation of X_fast_max as per section 3.2. This is used for idle 
periods to scale back the faster restart and is used for idle periods in 
minutes. As our tests are shorter than this in duration we have not 
implemented. We have however provided the framework for this so it would be 
trivial to complete this if desired.
    * the measurement of the receive rate in the last RTT as per section 4.2. 
We have left our implementation at the receive rate since last feedback sent 
for simplicity of implementation. We do not believe that this would have a 
material affect, and it would equally affect both the standard implementation 
and faster restart so it would be cancelled out.

Re: [PATCH 0/6] DCCP: Implement TFRC Faster Restart

[Gerrit Renker]

Ian -

|  This patch set implements TFRC Faster Restart as per current draft.
I have created a subtree `dccp_fr' which contains all these patches. It can
be pulled via
 
	git pull git://eden-feed.erg.abdn.ac.uk/dccp_exp dccp_fr

and, since it is a subtree of the main tree, it automatically inherits
it (ie. the branches are arranged dccp --> dccp_fr).

Let me know if you are happy with this. I am flexible regarding how to integrate
the trees (other branch arrangements are possible), but I would like to keep the
code in separate branches for a while:

* when updating to the forthcoming rev04 of the current rev03 of the Faster Restart
  draft, one needs to track the old changes and it is difficult to say now what the
  changes will look like

* there are some internal research comments in the code which help tracking rev03,
  but are specific only to FR implementation

* the CCID3 code is currently facing the following revisions
	- the current code implements rev00
	- Tommi's CCID4 relies on rev01 (not sure about Leandro's)
	- your FR code actually would need rev02
	- rev02 is in the process of being revised and obsoleted into rev03
	
Hope you are ok with this. If there are other/better suggestions, let me know.

Btw: your email client breaks long lines - most of the patches were broken along column 80 or so
     and needed manual fixing.

Re: [PATCH 0/6] DCCP: Implement TFRC Faster Restart

[Ian McDonald]

On 8/30/07, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> I have created a subtree `dccp_fr' which contains all these patches. It can
> be pulled via
>
>         git pull git://eden-feed.erg.abdn.ac.uk/dccp_exp dccp_fr
>
> and, since it is a subtree of the main tree, it automatically inherits
> it (ie. the branches are arranged dccp --> dccp_fr).
>
> Let me know if you are happy with this. I am flexible regarding how to integrate
> the trees (other branch arrangements are possible), but I would like to keep the
> code in separate branches for a while:

Yes I'm happy with this.
>
> * when updating to the forthcoming rev04 of the current rev03 of the Faster Restart
>   draft, one needs to track the old changes and it is difficult to say now what the
>   changes will look like
>
Agree. But don't think this is an obstacle to merging as we are
running obsolete code in other branch/mainline ;-)

> * there are some internal research comments in the code which help tracking rev03,
>   but are specific only to FR implementation
>
Can remove when needed.

> * the CCID3 code is currently facing the following revisions
>         - the current code implements rev00
>         - Tommi's CCID4 relies on rev01 (not sure about Leandro's)
>         - your FR code actually would need rev02
>         - rev02 is in the process of being revised and obsoleted into rev03
>
Agree all the versions are a mess. I think it's worthwhile starting on
upgrading the code base but not a project I'm undertaking at the
moment (or you).

> Hope you are ok with this. If there are other/better suggestions, let me know.
>
Yes absolutely fine.

> Btw: your email client breaks long lines - most of the patches were broken along column 80 or so
>      and needed manual fixing.

Sorry about that. Shifted to a different machine and configured KMail
but missed that one..

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

Re: [PATCH 0/6] DCCP: Implement TFRC Faster Restart

[Gerrit Renker]

|  > * when updating to the forthcoming rev04 of the current rev03 of the Faster Restart
|  >   draft, one needs to track the old changes and it is difficult to say now what the
|  >   changes will look like
|  >
|  Agree. But don't think this is an obstacle to merging as we are
|  running obsolete code in other branch/mainline ;-)
|
That is not what I meant. Of course it is not an obstacle of getting code `in', but the
problem is in getting the code `out' or updated when there is time for a new revision.

When there is little or no documentation in the code saying which variable or piece of
code belongs where, then each time someone wants to change a bit of code has to reverse-
engineer what actually is going on. This can be very time-consuming. So I was not thinking
in terms of merging (although I am sure that Arnaldo will pick out bad code), but of keeping
the code changeable for a longer period and easier to update.

Don't get me wrong, I don't mean your code here, it is a general problem which I think we
should pay more attention to. And, as said, my ideas of keeping things separate may not be
the best possible solution, only one that I could think of at the moment.

  
|  > * the CCID3 code is currently facing the following revisions
|  >         - the current code implements rev00
|  >         - Tommi's CCID4 relies on rev01 (not sure about Leandro's)
|  >         - your FR code actually would need rev02
|  >         - rev02 is in the process of being revised and obsoleted into rev03
|  >
|  Agree all the versions are a mess. I think it's worthwhile starting on
|  upgrading the code base but not a project I'm undertaking at the
|  moment (or you).
Hopefully there will be some IETF consolidation about rfc3448bis in December, then all this
could be reduced to one revision. 

Imagine -- 4 different developers and 3 different draft versions :(

Re: [PATCH 0/6] DCCP: Implement TFRC Faster Restart

[Ian McDonald]

On 9/5/07, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> |  Agree. But don't think this is an obstacle to merging as we are
> |  running obsolete code in other branch/mainline ;-)
> |
> That is not what I meant. Of course it is not an obstacle of getting code `in', but the
> problem is in getting the code `out' or updated when there is time for a new revision.
>
> When there is little or no documentation in the code saying which variable or piece of
> code belongs where, then each time someone wants to change a bit of code has to reverse-
> engineer what actually is going on. This can be very time-consuming. So I was not thinking
> in terms of merging (although I am sure that Arnaldo will pick out bad code), but of keeping
> the code changeable for a longer period and easier to update.
>
> Don't get me wrong, I don't mean your code here, it is a general problem which I think we
> should pay more attention to. And, as said, my ideas of keeping things separate may not be
> the best possible solution, only one that I could think of at the moment.
>
Aha. I see what you mean now. I think the best thing to do here is to
label each block of code introduced, that is specific to a version,
with the version of the document used.

I actually think my code could be merged into your main branch (when I
resubmit it fixed) as it does not conflict with anything and doesn't
run by default.

>
> |  > * the CCID3 code is currently facing the following revisions
> |  > - the current code implements rev00
> |  > - Tommi's CCID4 relies on rev01 (not sure about Leandro's)
> |  > - your FR code actually would need rev02
> |  > - rev02 is in the process of being revised and obsoleted into rev03
> |  >
> |  Agree all the versions are a mess. I think it's worthwhile starting on
> |  upgrading the code base but not a project I'm undertaking at the
> |  moment (or you).
> Hopefully there will be some IETF consolidation about rfc3448bis in December, then all this
> could be reduced to one revision.
>
> Imagine -- 4 different developers and 3 different draft versions :(
>
I'm in two minds about this one. On my one hand as Linux developer I
think we should always be working towards the latest version. On the
other hand as a researcher I want a known and consistent quantity.
Difficult one to resolve!

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

Re: [PATCH 0/6] DCCP: Implement TFRC Faster Restart

[Gerrit Renker]

|  > When there is little or no documentation in the code saying which variable or piece of
|  > code belongs where, then each time someone wants to change a bit of code has to reverse-
|  > engineer what actually is going on. This can be very time-consuming. So I was not thinking
|  > in terms of merging (although I am sure that Arnaldo will pick out bad code), but of keeping
|  > the code changeable for a longer period and easier to update.
|  >
|  > Don't get me wrong, I don't mean your code here, it is a general problem which I think we
|  > should pay more attention to. And, as said, my ideas of keeping things separate may not be
|  > the best possible solution, only one that I could think of at the moment.
|  >
|  Aha. I see what you mean now. I think the best thing to do here is to
|  label each block of code introduced, that is specific to a version,
|  with the version of the document used.
That's why I thought a separate branch would be nice - it keeps all documentation and patches together
so that even after some pauses in between one knows where the code came from and what it was good for. 

Will you be updating the code when the `real' Faster Restart comes out? We talked about this before,
the situation is that rev-03 is obsolete and in the progress of being replaced by a different approach, so 
the current incarnation is in a kind of disconnected limbo state. It is useful for testing, and that is
why I am certainly happy to track it in (a branch of) the tree; but it is clear that this Faster Restart
will be obsoleted in some future.

That is why I think a separate branch is better - it allows you, even after months of pause, to continue
with your Faster Restart work exactly where it was left previously.

Let me be clear - I don't want to get in the way of style discussions between you and Arnaldo, but I'd
like to keep the test tree as clearly structured as possible. What I don't know at the moment, and shall
investigate, is whether there are other ways of arranging the subtrees while still keeping different 
approaches separable (my understanding of a `branch').

Again, this is not a Faster Restart issue, but a general problem of moving targets. What I am taking
home from this is to make a mental note of annotating the current code with regard to which rfc3448bis
draft version is used (at least it is documented online in these archives).

There is a similar problem with CCID4, which is apparently an also much-discussed draft, and the TFRC-SP
specification is only an Experimental RFC (not Proposed Standard, like DCCP). I know from my own experience
with getting the code for RFC 3828 (a stable Proposed Standard RFC) merged into the mainline that
even then it took a long time and David Miller was not very sympathetic towards unfinished code: initially
I submitted only the IPv4 variant, but was asked to produce v6 also. I.e. when Faster Restart goes mainline,
I'd expect similar questions.

So, my hope is that if we can resolve this satisfactorily for you and all others involved, we will arrive
at a generic solution of distributed development, as I am quite sure that the problem of moving targets will 
persist in the DCCP world for some time to come.

Gerrit

Re: [PATCH 0/6] DCCP: Implement TFRC Faster Restart

[Ian McDonald]

On 9/5/07, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> |  Aha. I see what you mean now. I think the best thing to do here is to
> |  label each block of code introduced, that is specific to a version,
> |  with the version of the document used.
> That's why I thought a separate branch would be nice - it keeps all documentation and patches together
> so that even after some pauses in between one knows where the code came from and what it was good for.
>

That's fine by me.

> Will you be updating the code when the `real' Faster Restart comes out? We talked about this before,
> the situation is that rev-03 is obsolete and in the progress of being replaced by a different approach, so
> the current incarnation is in a kind of disconnected limbo state. It is useful for testing, and that is
> why I am certainly happy to track it in (a branch of) the tree; but it is clear that this Faster Restart
> will be obsoleted in some future.
>

I would be interested in doing so, but it all depends what else I am
doing when that comes around.

> That is why I think a separate branch is better - it allows you, even after months of pause, to continue
> with your Faster Restart work exactly where it was left previously.
>
Fine by me.

> Let me be clear - I don't want to get in the way of style discussions between you and Arnaldo, but I'd
> like to keep the test tree as clearly structured as possible. What I don't know at the moment, and shall
> investigate, is whether there are other ways of arranging the subtrees while still keeping different
> approaches separable (my understanding of a `branch').
>
It's no big issue really to me how it is stored. I have my
preferences, but I don't really care how it is actually done in the
end.


> So, my hope is that if we can resolve this satisfactorily for you and all others involved, we will arrive
> at a generic solution of distributed development, as I am quite sure that the problem of moving targets will
> persist in the DCCP world for some time to come.
>
It is resolved satisfactorily for me now.

Regards,

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

Re: [PATCH 0/6] DCCP: Implement TFRC Faster Restart

[Gerrit Renker]

Ok, thanks - I am looking forward to further collaboration and patches.

As said, the format of the test tree is not set in stone and I'd be happy to change it
and discuss alternatives - whichever way is best. 

It is also possible to store more stuff - that is what the thing consumes electrical
energy for. I.e. if the CCID4 folks want to store stuff, that's welcome too.


|  > |  Aha. I see what you mean now. I think the best thing to do here is to
|  > |  label each block of code introduced, that is specific to a version,
|  > |  with the version of the document used.
|  > That's why I thought a separate branch would be nice - it keeps all documentation and patches together
|  > so that even after some pauses in between one knows where the code came from and what it was good for.
|  >
|  
|  That's fine by me.

[PATCH 0/6] DCCP: Implement TFRC Faster Restart

[Ian McDonald]

(Resent with updates after Gerrit's review)

This patch set implements TFRC Faster Restart as per current draft.

Patche can also be found at:
http://wand.net.nz/~iam4/dccp/patches24/
(although do not apply patch 7)

The faster restart implementation was based on 
draft-ietf-dccp-tfrc-faster-restart-03.txt.

The version of DCCP CCID3 in Gerrit's tree used as the base is (mostly) 
draft-floyd-rfc3448bis-00.txt where the faster restart Internet Draft 
specifies the use of draft-ietf-dccp-rfc3448bis-02.txt.

We did not implement all of the Internet Draft for faster restart as it was 
either not required, or the base DCCP did not support the features required.

In particular the following features are missing:

    * keep alive pings as per section 3.1. It has been proposed at IETF 69 to 
remove these.
    * the use of X_recv_set as per section 3.2. We use X_recv instead as 
X_recv_set is not part of rfc3448bis-00.txt
    * Interpolation of X_fast_max as per section 3.2. This is used for idle 
periods to scale back the faster restart and is used for idle periods in 
minutes. As our tests are shorter than this in duration we have not 
implemented. We have however provided the framework for this so it would be 
trivial to complete this if desired.
    * the measurement of the receive rate in the last RTT as per section 4.2. 
We have left our implementation at the receive rate since last feedback sent 
for simplicity of implementation. We do not believe that this would have a 
material affect, and it would equally affect both the standard implementation 
and faster restart so it would be cancelled out.

Re: [PATCH 0/6] DCCP: Implement TFRC Faster Restart

[Gerrit Renker]

Quoting Ian McDonald:
|  (Resent with updates after Gerrit's review)
|  
|  This patch set implements TFRC Faster Restart as per current draft.
Thanks, updated the test tree. No time for the other (mine) patches today, will
reply to that later.