Subject: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 16 Jan 2014 08:36:47 +0000

Hi,

in March 2013, I asked if we're ready to adopt draft-singh-rmcat-cc-eval as a starting point towards our eval-criteria charter item. At that time, there consensus was that the WG wanted to wait a bit longer to see how the document would be evolving, and where our technical discussion in that area is going.

I'd like to open up that question again. As far as I know, there are still no other candidate documents, and in my personal opinion, Varun has been doing a good job in editing the draft and reflecting the discussions we've been having.

So, please reply with your thoughts on whether the WG should adopt draft-singh-rmcat-cc-eval towards our eval-criteria milestone. (Which was due in Aug 2013...)

Lars

---

From: Michael Welzl <[email-masked]>
Date: Thu, 16 Jan 2014 15:31:26 +0100

I vote for adoption.

BTW, speaking of the evaluation question, I did send an email regarding fairness to the list quite some time ago and got zero responses: http://www.ietf.org/mail-archive/web/rmcat/current/msg00680.html

In this email, I did propose a pretty simple way to settle the fairness issue, and I'd really like to know what the group thinks about it.

Cheers,
Michael

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Thu, 16 Jan 2014 15:57:51 +0000

Michael,

While not a commentary on your entire thread, I do have a nit with the following sentence in your post:

"Most congestion controls are RTT-dependent, so I guess this is something we'll just have to live with."

I think this is Chicken and Egg problem for the RMCAT design. Yes most congestion controls are RTT-dependent. But newer CCs (e.g., FAST TCP, see equation 1 at: http://netlab.caltech.edu/publications/fast-network05.pdf) have in their control loop an (adaptation)  gain which is RTT-dependent - effectively normalizing out the RTT for the purposes of making the rate of increase/decrease appropriate for the RTT it sees.

Assuming that our work will eventually have a delay-sensing component, we will certainly have visibility into the RTT and estimated one way delays (OWD). Thus I think ANY reasonable design of "the RMCAT algorithm" WOULD have a control loop rate adjustment that is dependent on OWD or RTT.

Just because old TCPs dynamics were sensitive to RTT doesn't mean that we have to propagate that oversight into our work.

Best,

Michael Ramalho,Ph.D.

From: rmcat [mailto:[email-masked]] On Behalf Of Michael Welzl
Sent: Thursday, January 16, 2014 9:31 AM
To: Eggert, Lars
Cc: rmcat WG
Subject: Re: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?

I vote for adoption.

Cheers,
Michael

Hi,

Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 16 Jan 2014 16:30:40 +0000

Hi,

please don't hijack this thread. It's for figuring out whether we have consensus on adopting draft-singh-rmcat-cc-eval.

Threads are cheap, start a new one :-)

Lars

On 2014-1-16, at 16:57, Michael Ramalho (mramalho) <[email-masked]> wrote:

> “Most congestion controls are RTT-dependent, so I guess this is something we'll just have to live with.”
>  
> I think this is Chicken and Egg problem for the RMCAT design. Yes most congestion controls are RTT-dependent. But newer CCs (e.g., FAST TCP, see equation 1 at: http://netlab.caltech.edu/publications/fast-network05.pdf) have in their control loop an (adaptation)  gain which is RTT-dependent – effectively normalizing out the RTT for the purposes of making the rate of increase/decrease appropriate for the RTT it sees.
>  
> Assuming that our work will eventually have a delay-sensing component, we will certainly have visibility into the RTT and estimated one way delays (OWD). Thus I think ANY reasonable design of “the RMCAT algorithm” WOULD have a control loop rate adjustment that is dependent on OWD or RTT.
>  
> Just because old TCPs dynamics were sensitive to RTT doesn’t mean that we have to propagate that oversight into our work.
>  
> Best,
>  
> Michael Ramalho,Ph.D.
>

---

From: Michael Welzl <[email-masked]>
Date: Fri, 17 Jan 2014 09:00:42 +0100

Hi,

I fixed the subject to avoid thread hijacking.

About your view on RTT-dependence, I could not agree more! When looking at the statement you quote from my email, perhaps it's possible to read between the lines that I'm not too happy with this compromise.

Indeed, for full control over fairness, RTT dependence is a hindrance, and yes it can indeed be fixed. You're right about FAST, but it can also be done without incorporating the RTT in the gain, when feedback is more than binary - I did this in my thesis  :-)    (*)

So yes, it's doable and it would be good. But I think that all the 3 current proposals are RTT-dependant...

Cheers,
Michael

(*) It can be achieved when there is some notion of the available capacity and one can relate a flow's own rate to it in some way - i.e. when we can make a rule like "if my share of the capacity is small, I increase a lot; if my share of the capacity is large, I increase little" (and vice versa for decrease, of course). This causes flows to increase/decrease based on their share of the capacity, not the RTT, irrespective of how often per RTT the rule is executed. In fact such a proportional control is used in LEDBAT, so perhaps LEDBAT's fairness is RTT-independent... dunno.

---

From: Ingemar Johansson S <[email-masked]>
Date: Sun, 19 Jan 2014 19:14:30 +0000

Hi

A comment on LEDBATs RTT dependency. I may be wrong here but I doubt that LEDBAT is RTT independent. The CWND growth function looks to me like Reno with appropriate byte counting save for the gain factor.I also recall that I have seen the effect that CWND grows slower when the RTT is longer (read longer geographical distance) when I experimented with a LEDBAT like congestion/flow control for realtime interacive media, one possible difference is that had to deviate a bit from the max_allowed_cwnd functions.
Provided that I am right.. It should not be too hard to make LEDBAT less RTT dependent, make the CWND function something like
cwnd += GAIN * F(RTT) * off_target * bytes_newly_acked * MSS / cwnd
Where F(RTT) is a function  of RTT, for instance F(RTT) = max(0.1,min(1.0, RTT/0.3)) and measuring RTT with LEDBAT is a no-brainer.

From: Michael Welzl [mailto:[email-masked]]
Sent: den 17 januari 2014 09:01
To: Michael Ramalho (mramalho)
Cc: rmcat WG
Subject: Re: [rmcat] Fairness

Hi,

Cheers,
Michael

Michael,

Best,

Michael Ramalho,Ph.D.

---

From: Nicolas KUHN <[email-masked]>
Date: Mon, 20 Jan 2014 09:57:31 +0100

Hi 

The GAIN parameter embodies LEDBAT's capability to react dynamically with OWD fluctuations. I believe that this reactivity (which is one key behaviour of LEDBAT) is linked to the gain, but to the RTT value as well. The larger the RTT, the slower the dynamic of LEDBAT. 
As an example, lets consider one "TCP-like" flow and one "LEDBAT" flow sharing a media. If the LEDBAT flow transmits data over a long delay link, but the TCP connexion does not, LEDBAT would probably react slower than the TCP connexion to the congestion events, and LEDBAT would not have a less-than-best-effort behaviour. According to me, this justify that the RTT's dependency of LEDBAT should be assessed. 

However, the issues which have been denoted recently [0,1] illustrate that the algorithm of LEDBAT should be seriously improved, due to the difficulty to choose a right TARGET/GAIN couple. Indeed, fixed parameters are always an issue to determine (why those 100ms for the target?) and those fixes you propose ((F(RTT)=max(0.1,min(1.0, RTT/0.3))) would encounter the same setting problems. 

I believe efforts should not be done towards improvements in the CWND evolution, but in changing LEDBAT's algorithm.

Nicolas KUHN

[0] David Ros, Michael Welzl: Assessing LEDBAT's Delay Impact.
[1] Kuhn, Nicolas and Mehani, Olivier and Sathiaseelan, Arjuna and Lochin, Emmanuel Less-than-Best-Effort capacity sharing over high BDP networks with LEDBAT [http://oatao.univ-toulouse.fr/9196/]

---

From: Michael Welzl <[email-masked]>
Date: Mon, 20 Jan 2014 10:30:05 +0100

+1 - I think this discussion has side-tracked because of my guess that LEDBAT could possibly be RTT-independent. My apologies, I didn't want to provoke that.

I think this group has decided long ago that it doesn't want to work with LEDBAT but with a new scheme.

Getting back to the main issue at hand: can we require RTT-independence? I'd like to, if indeed we can!

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 20 Jan 2014 09:42:16 +0000

Hi

I have probably missed this, but when was it decided that the group does not want to work on LEDBAT ?

/Ingemar

From: Michael Welzl [mailto:[email-masked]]
Sent: den 20 januari 2014 10:30
To: Nicolas KUHN
Cc: Ingemar Johansson S; Michael Ramalho (mramalho); rmcat WG
Subject: Re: [rmcat] Fairness

Hi

Nicolas KUHN

[0] David Ros, Michael Welzl: Assessing LEDBAT's Delay Impact.
[1] Kuhn, Nicolas and Mehani, Olivier and Sathiaseelan, Arjuna and Lochin, Emmanuel Less-than-Best-Effort capacity sharing over high BDP networks with LEDBAT [http://oatao.univ-toulouse.fr/9196/]<http://oatao.univ-toulouse.fr/9196/%5d>

On Jan 19, 2014, at 8:14 PM, Ingemar Johansson S <[email-masked]<mailto:[email-masked]>> wrote:

Hi

From: Michael Welzl [mailto:[email-masked]<http://ifi.uio.no/>]
Sent: den 17 januari 2014 09:01
To: Michael Ramalho (mramalho)
Cc: rmcat WG
Subject: Re: [rmcat] Fairness

Hi,

Cheers,
Michael

Michael,

Best,

Michael Ramalho,Ph.D.

---

From: Michael Welzl <[email-masked]>
Date: Mon, 20 Jan 2014 10:49:56 +0100

I don't think there was a formal decision - it was just my impression:

1) "LEDBAT isn't what we want" - style things were said in presentations and very early on in the mailing list (before the group really came into being, I think)

2) nobody has yet proposed it as a mechanism for RMCAT...

Cheers,
Michael

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 20 Jan 2014 09:58:06 +0000

OK, then I understand, thanks

/Ingemar

From: Michael Welzl [mailto:[email-masked]]
Sent: den 20 januari 2014 10:50
To: Ingemar Johansson S
Cc: Nicolas KUHN; Michael Ramalho (mramalho); rmcat WG
Subject: Re: [rmcat] Fairness

Cheers,
Michael

Hi

/Ingemar

Hi

Nicolas KUHN

Hi

Hi,

Cheers,
Michael

Michael,

Best,

Michael Ramalho,Ph.D.

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Mon, 20 Jan 2014 14:22:47 +0000

[Jeez, thanks Michael Welzl for this thread.]

Re: LEDBAT & RMCAT

During the design team meetings, the members assumed that LEDBAT transport was targeted toward a lower-than-best-effort AND likely less aggressive than our real-time transport needs.

Although there was no serious proposal to modify LEDBAT for RMCAT purposes (like Dr. Welzl states), the design team DID propose competing with it in evaluation experiments. This was primarily to make sure some weird interaction did not exist and that the LEDBAT flow backed off appropriately when we filled up the bottleneck with other TCP and RMCAT traffic (although we didn't know what "appropriately" meant in this context). And now I don't know what to set the RTT for the LEDBAT flows to (thanks Nicolas ;-) ).

Re: RMCAT & RTT-dependence/independence

This part of the thread began when I brought up FAST TCP (see links below) as an example of the case where the RATES of increase/decrease WERE DESIGNED to be a function of the RTT. My understanding was that this was done so that long-RTT flows were not disadvantaged by short-RTT flows.

The RMCAT design team HAS proposed testing the resulting algorithm with respect to "RTT-fairness" by proposing the mixing of RMCAT flows with different RTTs (two different delays) in a bottleneck.

Thus, it is my hope that any resulting RMCAT adaptation algorithm has accommodation for adaptation by the inclusion of a gain term that is a function of the RTT (or OWD) and that we do NOT repeat the same mistake that the original TCP did by not including such a component. That was the main point in my commentary.

Summary:

I hope that the above puts all the commentary of this thread in context (and that I didn't open up a new can of worms).

Michael Ramalho, Ph.D.

From: Ingemar Johansson S [mailto:[email-masked]]
Sent: Monday, January 20, 2014 4:58 AM
To: Michael Welzl
Cc: Nicolas KUHN; Michael Ramalho (mramalho); rmcat WG
Subject: RE: [rmcat] Fairness

/Ingemar

Cheers,
Michael

Hi

/Ingemar

Hi

Nicolas KUHN

Hi

Hi,

Cheers,
Michael

Michael,

Best,

Michael Ramalho,Ph.D.

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 21 Jan 2014 12:53:48 +0000

> I vote for adoption.

Anyone else care to state an opinion?

Thanks,
Lars

---

From: Luca De Cicco <[email-masked]>
Date: Tue, 21 Jan 2014 13:57:45 +0100

I vote for the adoption.

Cheers,
--
Luca De Cicco, PhD, Eng.
Politecnico di Bari
Dipartimento di Elettrotecnica ed Elettronica
Via Re David, 200 - Bari - ITALY
Office: +39 080 596 3851
http://c3lab.poliba.it/index.php/LDC

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Tue, 21 Jan 2014 13:34:34 +0000

Hi,

I am in favor of adoption however there were some comments (in the last IETF meeting) about splitting the current draft into two- separating the usecases in another draft. I heard Varun in favored of doing that as well. 

Will there be separation in the next version of this draft and we adopt both of them? What is the possibility that the current eval draft is adopted as it is then separate it later?

BR

Zahed

===============================================================================
ANM ZAHEDUZZAMAN SARKER 
Multimedia Technologies

Ericsson
Laboratoriegränd 11
97128 Luleå, Sweden
Phone +46 10 717 37 43
Mobile +46 76 115 37 43
Office +46 76 115 37 43
Fax +46 920 996 21
[email-masked]
www.ericsson.com
===============================================================================

> -----Original Message-----
> From: rmcat [mailto:[email-masked]] On Behalf Of Eggert, Lars
> Sent: den 21 januari 2014 13:54
> To: rmcat WG
> Importance: High

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 21 Jan 2014 13:49:10 +0000

Hi,

On 2014-1-21, at 14:34, Zaheduzzaman Sarker <[email-masked]> wrote:
> I am in favor of adoption

noted

> however there were some comments (in the last IETF meeting) about splitting the current draft into two- separating the usecases in another draft. I heard Varun in favored of doing that as well. 
> 

There need not be a 1:1 mapping between charter work items/milestones and WG drafts. So IMO we are free to address a charter item with a set of related documents, if that is the best way to organize the material. And whether we split it now or later doesn't matter. IMO.

Lars

---

From: Saverio Mascolo <[email-masked]>
Date: Tue, 21 Jan 2014 16:53:47 +0100

I vote for the adoption

saverio mascolo

On Thu, Jan 16, 2014 at 9:36 AM, Eggert, Lars <[email-masked]> wrote:

> Hi,
>
> in March 2013, I asked if we're ready to adopt draft-singh-rmcat-cc-eval
> as a starting point towards our eval-criteria charter item. At that time,
> there consensus was that the WG wanted to wait a bit longer to see how the
> document would be evolving, and where our technical discussion in that area
> is going.
>
> I'd like to open up that question again. As far as I know, there are still
> no other candidate documents, and in my personal opinion, Varun has been
> doing a good job in editing the draft and reflecting the discussions we've
> been having.
>
> So, please reply with your thoughts on whether the WG should adopt
> draft-singh-rmcat-cc-eval towards our eval-criteria milestone. (Which was
> due in Aug 2013...)
>
> Lars
>

-- 
Saverio Mascolo, Full Professor
Dipartimento di Elettrotecnica ed Elettronica
Politecnico di Bari
Via Orabona 4, 70125 Bari Italy
Tel. +39 080 5963621
Fax. +39 080 5963410
email:[email-masked]

http://c3lab.poliba.it

=================================
 This message may contain confidential and/or legally privileged
information.
  If you are not the intended recipient of the message, please destroy it.
 Any unauthorized dissemination, distribution, or copying of the material in
 this message, and any attachments to the message, is strictly forbidden.

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 21 Jan 2014 17:22:00 -0500

> Anyone else care to state an opinion?

I think it should be adopted (though I don't "vote" for it, since
our t-shirts say we reject voting).

-- 
Wes Eddy
MTI Systems

---

From: "Van Der Auwera, Geert" <[email-masked]>
Date: Wed, 22 Jan 2014 00:50:04 +0000

Hi,

I am also in favor of adoption.

Best regards,

Geert Van der Auwera

-----Original Message-----
From: rmcat [mailto:[email-masked]] On Behalf Of Zaheduzzaman Sarker
Sent: Tuesday, January 21, 2014 5:35 AM
To: Eggert, Lars; rmcat WG
Subject: Re: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?

Hi,

BR

Zahed

Ericsson
Laboratoriegränd 11
97128 Luleå, Sweden
Phone +46 10 717 37 43
Mobile +46 76 115 37 43
Office +46 76 115 37 43
Fax +46 920 996 21

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 22 Jan 2014 10:30:45 +0000

Thanks for the feedback so far. We'll leave the call open until Jan 30 (= two weeks from the start) and then make a decision.

Lars

---

From: Randell Jesup <[email-masked]>
Date: Wed, 22 Jan 2014 14:28:00 -0500

I'm in favor of adoption

-- 
Randell Jesup -- rjesup a t mozilla d o t com

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 23 Jan 2014 16:34:08 +0000

I support adopting this draft for eval-criteria work items.

Mo

---

From: Piers O'Hanlon <[email-masked]>
Date: Wed, 29 Jan 2014 15:22:50 +0000

Hi,

I support the draft, though I still think some more work is needed to bring the requirements and this draft in line with each other.

Piers

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 31 Jan 2014 10:41:22 +0000

Hi,

OK, I think we've seen strong consensus to adopt draft-singh-rmcat-cc-eval as a starting point for our eval-criteria work item.

Varun, please submit the next revision as draft-ietf-rmcat-eval-criteria-00.

Lars