Subject: [rmcat] time to get active

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 27 Feb 2013 18:09:26 +0000

Hi,

the group has been entirely too silent since IETF-86 in Atlanta. We now have new revisions of a bunch of drafts available that are aiming for adoption towards our first milestone work items.

Please review these drafts now and comment on the list! We would very much be able to focs the discussion in Orlando on the key issues, rather than doing rundowns through all the changes.

Thanks,
Lars

---

From: Matt Mathis <[email-masked]>
Date: Wed, 27 Feb 2013 10:35:23 -0800

Did we perhaps address all of the hard problems in the charter process, so
now there is nothing to controversial to chew on?

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat privacy and
security as matters of life and death, because for some users, they are.

On Wed, Feb 27, 2013 at 10:09 AM, Eggert, Lars <[email-masked]> wrote:

> Hi,
>
> the group has been entirely too silent since IETF-86 in Atlanta. We now
> have new revisions of a bunch of drafts available that are aiming for
> adoption towards our first milestone work items.
>
> Please review these drafts now and comment on the list! We would very much
> be able to focs the discussion in Orlando on the key issues, rather than
> doing rundowns through all the changes.
>
> Thanks,
> Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 27 Feb 2013 18:37:41 +0000

> now there is nothing to controversial to chew on?

I wish...

Lars

---

From: ken carlberg <[email-masked]>
Date: Wed, 27 Feb 2013 14:13:11 -0500

well, perhaps I can get the ball rolling in terms of a headache to chew on :-)

The second requirement in draft-jesup-rmcat-reqs-01.txt is...

  2.   The algorithm must be fair to other flows, both realtime flows
        (such as other instances of itself), and TCP flows, both long-
        lived and bursts such as the traffic generated by a typical web
        browsing session.  Note that 'fair' is a rather hard-to-define
        term.

        A.  The algorithm must not overreact to short-term bursts (such
            as web-browsing) which can quickly saturate a local-
            bottleneck router or link, but also clear quickly, and
            should recover quickly when the burst ends.

        B.  We will need make some evaluation of fairness, but deciding
            what is "fair" is a tough question and likely to be
            partially subjective, but we should specify some of the
            inputs needed in order to select among algorithms and
            tunings presented as options.

however, the document does not have a definition of the term "fair" or "fairness".  And while the document points us to terminology in another draft (draft-ietf-rtcweb-overview-06.txt), this other draft doesn't even mention "fair" or fairness".  I think one nit is that the RMCAT requirements draft needs its own terminology section instead of pointing to another draft.

And more importantly, I think we need to bite the bullet and decide what is "fair" / "fairness".  It just doesn't seem possible for us to say that the algorithms *must* be fair, but then punt in defining what is (or perhaps, what is not) fair.  And I'm definitely not meaning to beat up on the author, but rather ourselves.

As a starting point, and in the context of real time apps, I don't think we need to be fair to a continual series of parallel short transaction flows.  Rather, I would prefer to be fair, or focus our attention, to longer transaction flows.

thoughts?  Have I missed something?

-ken

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 28 Feb 2013 07:58:57 +0000

Hi,

> well, perhaps I can get the ball rolling in terms of a headache to chew on :-)

thanks, Ken!

> however, the document does not have a definition of the term "fair" or "fairness".  And while the document points us to terminology in another draft (draft-ietf-rtcweb-overview-06.txt), this other…

agreed. Or at least it should point to a draft that has a concrete definition we agree on. 

(Varun's rmcat-cc-eval draft also needs to align with that definition; it already has a corresponding editor's note.)

> And more importantly, I think we need to bite the bullet and decide what is "fair" / "fairness".  It just doesn't seem possible for us to say that the algorithms *must* be fair, but then punt in de…

Agreed.

Lars

---

From: Piers O'Hanlon <[email-masked]>
Date: Thu, 28 Feb 2013 09:33:36 +0000

Hi,

When I was reading over the requirements doc the lack of a fairness measure had also come to my attention - it seemed to me that we should probably at least reference the list of fairness measures in RFC5166 in section 4.7 of draft-singh-rmcat-cc-eval - or develop a revised list of fairness measures. Some new aspects of fairness may arise when one attempts to run delay based algorithms (potentially with differing delay bounds) against lost based algorithms.... How do we quantify the 'delay fairness'?

Another thing that concerns me is the issue of talking about 'available' bandwidth in section 3 - it seems to me that the 'available' bandwidth (as in unused available bandwidth) may not be the best metric. This is because existing conventional congestion control (e.g. TCP) will attempt utilise more than the 'available' bandwidth - which is what one should expect - so a new flow is often not only taking the 'available' bandwidth but also taking it's 'fair' share - which is little harder to define...

Piers

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 28 Feb 2013 11:28:19 +0100

Hi,

here my personal option:

> And more importantly, I think we need to bite the bullet and decide what is
> "fair" / "fairness".  It just doesn't seem possible for us to say that the
> algorithms *must* be fair, but then punt in defining what is (or perhaps,
> what is not) fair.  And I'm definitely not meaning to beat up on the
> author, but rather ourselves.
>
> As a starting point, and in the context of real time apps, I don't think we
> need to be fair to a continual series of parallel short transaction flows. 
> Rather, I would prefer to be fair, or focus our attention, to longer
> transaction flows.

We might not even want to talk about fairness at all. Instead we want to 
ensure that we do not throttle down the competing flows completely and that 
we (as well as others) get an appropriate share of the available bandwidth. 
That might not be much easier to define, but fairness seems to be the wrong 
term and is often directly linked to tcp-friendliness.

Mirja 

> >> Did we perhaps address all of the hard problems in the charter process,
> >> so now there is nothing to controversial to chew on?
> >
> > I wish...
> >
> > Lars

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 28 Feb 2013 11:54:05 -0500

> term and is often directly linked to tcp-friendliness.

I kind of agree.

"Non-destructiveness" to other traffic is the property to look for.

-- 
Wes Eddy
MTI Systems

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 28 Feb 2013 22:27:17 -0800

I agree that "fairness" isn't a goal. Hybrid algorithms (e.g. Delay based unless competing with loss-based),  try to avoid building queues unless that would lead to starvation. However once you starve 'em, they get ornery and can swipe at other flows like two cats in a fight.  Which part should we focus on for "fairness", the polite sniffing around the bowl or the all out cat fight? When someone says my cat isn't fair, I will want to know :)