Pasi Sarolahti | 18 Jan 21:13 2010
Picon
Picon

DCCP and IETF-77

Hello,

We should soon decide whether DCCP needs to meet in the next IETF. By  
the next meeting we are expecting to have just one active WG draft, on  
UDP encapsulation, about which I sent a query earlier. Therefore, we  
would like to probe if there are any other topics we should discuss in  
Anaheim. If there not many topics to discuss, it probably isn't  
necessary to schedule a DCCP session. In this case we could try to ask  
agenda time from some related working group to discuss UDP  
encapsulation. It was mentioned earlier that TSVWG would be quite  
close to this work.

If you have a topic you'd like to discuss in DCCP meeting, please let  
the chairs know within the next couple of weeks.

Thanks!

- Pasi & Tom

Michael Welzl | 19 Jan 10:19 2010
Picon
Picon

Re: DCCP and IETF-77

Hi,

I believe that we're going to see a few reviews of MulTFRC:
http://www.ietf.org/id/draft-welzl-multfrc-01.txt
in the ICCRG group's mailing list very soon.
(within the next few days, hopefully).

If these, and possibly the outcome of the ensuing discussion,
are favorable enough in your opinion, I'd like to make another
request for our MulTFRC draft to become a WG item.

For this, I'd come to Anaheim and request that on site
if that makes sense to you.

Cheers,
Michael

On Jan 18, 2010, at 9:13 PM, Pasi Sarolahti wrote:

> Hello,
>
> We should soon decide whether DCCP needs to meet in the next IETF.  
> By the next meeting we are expecting to have just one active WG  
> draft, on UDP encapsulation, about which I sent a query earlier.  
> Therefore, we would like to probe if there are any other topics we  
> should discuss in Anaheim. If there not many topics to discuss, it  
> probably isn't necessary to schedule a DCCP session. In this case we  
> could try to ask agenda time from some related working group to  
> discuss UDP encapsulation. It was mentioned earlier that TSVWG would  
> be quite close to this work.
(Continue reading)

Phelan, Tom | 19 Jan 17:44 2010

Re: DCCP and IETF-77

Hi Michael,

Thanks for the input.  Hopefully you'll get some good feedback and we
can go forward with this.

Tom P.

> -----Original Message-----
> From: dccp-bounces <at> ietf.org [mailto:dccp-bounces <at> ietf.org] On Behalf
Of
> Michael Welzl
> Sent: Tuesday, January 19, 2010 4:19 AM
> To: Pasi Sarolahti
> Cc: DCCP working group; Dragana Damjanovic
> Subject: Re: [dccp] DCCP and IETF-77
> 
> Hi,
> 
> I believe that we're going to see a few reviews of MulTFRC:
> http://www.ietf.org/id/draft-welzl-multfrc-01.txt
> in the ICCRG group's mailing list very soon.
> (within the next few days, hopefully).
> 
> If these, and possibly the outcome of the ensuing discussion,
> are favorable enough in your opinion, I'd like to make another
> request for our MulTFRC draft to become a WG item.
> 
> For this, I'd come to Anaheim and request that on site
> if that makes sense to you.
> 
(Continue reading)

Picon

evaluation of MulTFRC

In response to the interest in possibly specifying MulTFRC
as a mechanism for DCCP, and the call for reviews in the
ICCRG, I've looked at the available material.

This is my personal review, and not an ICCRG consensus.  I
know at least Lachlan has also been looking at this, and
may have come to a different conclusion.

I think there's no reason to block this if there's momentum
to do the work in DCCP.  While there are definitely some
concerns with the goal and approach, it seems to me that
they aren't likely to cause any serious damage to the Internet.
It's certainly not as dangerous as things people have done in
the past, which the Internet survived :).

That's the executive summary, some more detailed listing
of thoughts is below.  Chatting with Lachlan helped to
formulate some of these positions of mine (in response
to points he made), but I think he should probably post
his own thoughts separately as he may not agree with my
overall feelings.

One concern is that this is equation-based rather than
window-based, and thus will not back-off as quickly as TCP
under loss.  However, if it works correctly, then it will
respond as TFRC flows do, and TFRC has been around for a
while without disaster, so this doesn't really worry me.

A related concern that came to light when I was discussing
this with Lachlan is that there may be difficulties with
(Continue reading)

Pasi Sarolahti | 20 Jan 02:11 2010
Picon
Picon

Re: evaluation of MulTFRC

Thanks, Wes, for the good review! This was very helpful.

- Pasi

On Jan 19, 2010, at 12:02 PM, Eddy, Wesley M. (GRC-MS00)[ASRC  
AEROSPACE CORP] wrote:

> In response to the interest in possibly specifying MulTFRC
> as a mechanism for DCCP, and the call for reviews in the
> ICCRG, I've looked at the available material.
>
> This is my personal review, and not an ICCRG consensus.  I
> know at least Lachlan has also been looking at this, and
> may have come to a different conclusion.
>
> I think there's no reason to block this if there's momentum
> to do the work in DCCP.  While there are definitely some
> concerns with the goal and approach, it seems to me that
> they aren't likely to cause any serious damage to the Internet.
> It's certainly not as dangerous as things people have done in
> the past, which the Internet survived :).
>
> That's the executive summary, some more detailed listing
> of thoughts is below.  Chatting with Lachlan helped to
> formulate some of these positions of mine (in response
> to points he made), but I think he should probably post
> his own thoughts separately as he may not agree with my
> overall feelings.
>
> One concern is that this is equation-based rather than
(Continue reading)

Michael Welzl | 20 Jan 10:08 2010
Picon
Picon

Fwd: [Iccrg] evaluation of MulTFRC


> (forwarded on behalf of Lachlan who's not subscribed
to DCCP)

> ---------- Forwarded message ----------
> From: Lachlan Andrew <lachlan.andrew <at> gmail.com>
> To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <wesley.m.eddy <at> nasa.gov 
> >
> Date: Wed, 20 Jan 2010 13:02:13 +1100
> Subject: Re: [Iccrg] evaluation of MulTFRC
> 2010/1/20 Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
> <wesley.m.eddy <at> nasa.gov>:
>> In response to the interest in possibly specifying MulTFRC
>> as a mechanism for DCCP, and the call for reviews in the
>> ICCRG, I've looked at the available material.
>>
>> This is my personal review, and not an ICCRG consensus.  I
>> know at least Lachlan has also been looking at this, and
>> may have come to a different conclusion.
>
>
> Thanks, Wes.  My review (also my opinions, not ICCRG consensus) is  
> below.
>
>
> My technical concerns with MulTFRC are:
>
> - The formula for the rate is quite complex.  This makes it likely for
> implementation errors.  It also makes it hard to check for complete
> safety.  This is especially so since the draft does not specify which
(Continue reading)

Michael Welzl | 20 Jan 10:26 2010
Picon
Picon

Fwd: [Iccrg] MulTFRC draft review

That's the third (and last) review. Discussion will take
place in the ICCRG list. To join, or see the web archive,
go to:

Cheers,
Michael


Begin forwarded message:

From: Dirceu Cavendish <dirceu_cavendish <at> yahoo.com>
Date: January 20, 2010 9:07:06 AM GMT+01:00
To: iccrg IRTF list <iccrg <at> cs.ucl.ac.uk>
Subject: [Iccrg] MulTFRC draft review

Here is my quick review to Welzl's draft on MulTFRC.
 
The abstract of the draft has a rather weak motivation. I think the abstract should be strenghtened, so as to make a stronger case for the need of the draft. Is the motivation to provide a mechanism to tune the aggressiveness of TFRC?
 
New equation X_Bps: Some explanation so as to why or at least a pointer to a paper that describes the equation derivation and properties is in order.The pointer provided [Dam+08] presents the results, and points to a tech report for derivation.The important point, however, is to have an idea of the range of rates produced by the equation. The original TFRC equation is much easier to understand and make a "safety" analysis of Bps possible range values than the proposed new equation IMHO.
 
An implementation consideration session is also helpful to discuss issues such as how to work around the lack of floating point operations in Linux Kernel, for instance...
 
Dirceu
 
 
 
 
 

_______________________________________________
Iccrg mailing list
Iccrg <at> cs.ucl.ac.uk
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

Lars Eggert | 20 Jan 14:28 2010
Picon

Re: Fwd: [Iccrg] MulTFRC draft review

Hi,

Michael asked on the ICCRG list for people to comment whether MulTFRC should be a WG item here.

My personal (all hats off) belief is that DCCP should focus on work items that increase DCCP and TFRC
deployment. Frankly, I don't think that "porting" an old and unused idea (MulTCP) to TFRC is going to lead
to that.

I'm not opposed to the WG taking this on is they absolutely want. I mainly don't see a reason for this to be a
DCCP WG Experimental RFC vs. an ICCRG Experimental RFC.

Lars
Attachment (smime.p7s): application/pkcs7-signature, 3364 bytes
Michael Welzl | 20 Jan 14:45 2010
Picon
Picon

Re: Fwd: [Iccrg] MulTFRC draft review

On Jan 20, 2010, at 2:28 PM, Lars Eggert wrote:

> Hi,
>
> Michael asked on the ICCRG list for people to comment whether  
> MulTFRC should be a WG item here.
>
> My personal (all hats off) belief is that DCCP should focus on work  
> items that increase DCCP and TFRC deployment. Frankly, I don't think  
> that "porting" an old and unused idea (MulTCP) to TFRC is going to  
> lead to that.

I completely agree about your first sentence (but maybe
restricting it to DCCP, not TFRC). And what would increase
deployment? Something that makes the protocol attractive to
its potential users ( = developers of multimedia applications).
The service provided by existing CCIDs such as TFRC ("smooth
rate and TCP-friendly") doesn't seem to be very attractive
from that perspective to me - and MulTFRC adds a lot to that.

I (quite obviously  :-)  ) disagree about your second sentence.

1) MulTFRC is really much more than merely "porting"
MulTCP to TFRC - one reason why MulTCP might not have
been used is that it simply doesn't work very well, its
operational range is extremely limited (as opposed to
MulTFRC, as we've shown in our CCR paper). Another one
might have been lack of a proper implementation and
specification, and we're trying to address both in case
of MulTFRC.

2) Why isn't it worth trying, especially when we don't
seem to have other proposals on the table that would
foster DCCP deployment?

> I'm not opposed to the WG taking this on is they absolutely want. I  
> mainly don't see a reason for this to be a DCCP WG Experimental RFC  
> vs. an ICCRG Experimental RFC.

Just to understand, does this "vs." mean that it could
just as well be an ICCRG Experimental RFC in your
opinion, i.e. you're only stating your opinion about these
two choices here, and not about having MulTFRC as an
Experimental RFC at all or not?

Cheers,
Michael

Lars Eggert | 20 Jan 15:05 2010
Picon

Re: Fwd: [Iccrg] MulTFRC draft review

Hi,

On 2010-1-20, at 15:45, Michael Welzl wrote:
>> I'm not opposed to the WG taking this on is they absolutely want. I  
>> mainly don't see a reason for this to be a DCCP WG Experimental RFC  
>> vs. an ICCRG Experimental RFC.
> 
> Just to understand, does this "vs." mean that it could
> just as well be an ICCRG Experimental RFC in your
> opinion, i.e. you're only stating your opinion about these
> two choices here, and not about having MulTFRC as an
> Experimental RFC at all or not?

correct. I have no issues with ICCRG publishing it, but I don't see why the WG should, at least at this point.

Lars
Attachment (smime.p7s): application/pkcs7-signature, 3364 bytes

Gmane