Hi,

See below a comment about one bit in the meeting minutes:

On Mon, Jul 1, 2013 at 3:10 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:
RMCAT Eval Design Team Meeting

Monday, July 1, 2013, 11:00AM New York Time (EDT UTC-4)

(snip)

  - Should RMCAT solution candidates explicitly support weighted fairness? Mandatory, optional, or prohibited?

  - The requirements draft does not mention weighted fairness nor equal-rate fairness, just that fairness is �a hard-to-define term�, �a tough question�. Need to decide what firmer position the req draft should take, so further drafts (eval, candidates, etc.) have clear reqs.

  - It was noted that in the absence of weighted fairness within RMCAT itself, applications will game multiple RMCATs to achieve weighted fairness.

DTM> Mentions were made about updating Randell's draft to see if weighted fairness should be a general requirement of an RMCAT implementation.

Weighted fairness is requirement F34 in
http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-10

� to address this requirement, the "identifying and controlling groups of flows" milestone ended up in the charter. Therefore I think there should be no debate about "do we want to support this?".
-- 

Zahed

==================================================
ANM ZAHEDUZZAMAN SARKER 

Ericsson AB
Multimedia Technologies
Laboratoriegr�nd 11
97128 Lule�, Sweden
Phone +46 10 717 37 43
Fax +46 920 996 21
SMS/MMS +46 76 115 37 43
zaheduzzaman.sarker@ericsson.com
www.ericsson.com

==================================================
Michael,

Thanks for your reply. I think you and Zahed were talking past each other.

On the RMCAT design team call, the "weighted fairness topic" came up in the context of Case 2 (weighted fairness BETWEEN different RMCAT associations). The "between sessions" topic was initiated by Xiaoqing Zhu (as that is what a NADA does - see her draft for that). I believe that Case 2 was the context behind Zahed's reply.

>From what I understand, your draft deals primarily with Case 1 (within a single RMCAT session/association/whatever-we-will-call-it). And I believe that was the context of your reply.

And now we all agree that our initial work should focus on RMCAT fairness for flows with equal priority ... and that RTT-fairness is a desirable but not-yet-determined-to-be-feasible goal.

Michael Ramalho

PS - Fairness independent of RTT may be attainable, but it would need to be measured on timescales that are many multiples of the RMCAT flow with the largest RTT. This is because the maximum time rate of change of the BW estimate must be a function of the RTT (feedback is not instantaneous). This is easily seen in the dynamics of any window-based congestion control (such as TCP). Indeed, "end-to-end capacity" may need to be defined via a bandwidth measure on a similar timescale (this is a shortcoming of many IETF drafts - where they just say "capacity" without even defining it ...  but I digress).

-----Original Message-----
From: Michael Welzl [mailto:michawe@ifi.uio.no] 
Sent: Friday, July 05, 2013 12:30 PM
To: Michael Ramalho (mramalho)
Cc: Zaheduzzaman Sarker; Dan Weber; Mo Zanaty (mzanaty); rmcat@ietf.org
Subject: Re: [rmcat] Design Team Meeting Minutes & Recording July 1

Hi,

I'll try to summarize in what I think are simpler words (but sticking to SCTP terminology):
case 1: priorities WITHIN a single RMCAT association case 2: priorities BETWEEN multiple RMCAT associations (which may embed case 1, i.e. one RMCAT asocation may have multiple flows with priorities between them)

I think we agree that supporting case 1 is a must. Supporting case 2, however, is much more difficult, and may not even be a reasonable goal to pursue when we're at the same time trying to be roughly TCP-compatible and minimize delay. It might be possible to do this in some way, but I would prefer to avoid dealing with case 2, I was only concerned with case 1. I do not believe that anyone expects us to solve case 2.

I see that case 1 may not be what you were concerned with when discussing "weighted fairness", but enabling case 1 with a method akin to the one in our coupled-cc draft still requires that some external entity can set the rate of a flow to a rate that wasn't determined by it. That is a bit unusual and should be a part of the tests that people should do with their mechanisms, I think. Yes, I am sorry for not having brought this up earlier!

Cheers,
Michael

On Jul 5, 2013, at 6:11 PM, "Michael Ramalho (mramalho)" <mramalho@cisco.com> wrote:

Michael & Zahed (mostly),

The thread below is a little rugged ... so let me just comment here at the top ;-).

The RTCWeb requirement F34 (The browser MUST support prioritization of streams and data) can be taken at least two different ways of importance to RMCAT.

The first way is that RMCAT transport should provide an API to the application that allows it to "appropriately prioritize" the application traffic provided to it when it puts that traffic on the wire. I think that will eventually be a must - although we are still quite far from specifying how that API behaves as we aren't done at the transport level yet ;-). Obviously, the prioritization of flows within one host is doable with information on that one host.

The second way applies when ALL FLOWS through a bottleneck are RMCAT flows - and that a given RMCAT association (borrowing SCTP terminology here) could have multiple RMCAT streams of various priorities within it. Let's say your RMCAT association has streams of different priorities. Then you could have a desire  to compete fairly IN PRIORITY with other RMCAT streams of priority foo. That is a MUCH harder requirement. And possibly impossible if your flow is mixing with other existing transports.

Is it your understanding that RTCWeb hopes we  (RMCAT) handle the second case? And if so, with what desired mechanism (perhaps congestion control rate estimation be a function of the priority value provided to the RMCAT transport - but that only works with an assumed traffic mix at the bottleneck - which is unknowable at a given host)?

Thanks for your input ...

Michael Ramalho

-----Original Message-----
From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf 
Of Michael Welzl
Sent: Thursday, July 04, 2013 4:14 PM
To: Zaheduzzaman Sarker
Cc: Dan Weber; Mo Zanaty (mzanaty); rmcat@ietf.org
Subject: Re: [rmcat] Design Team Meeting Minutes & Recording July 1

On Jul 4, 2013, at 9:06 PM, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> wrote:

Hi,

My comment below.

BR
Zahed
On 2013-07-03 15:41, Michael Welzl wrote:

Hi,

See below a comment about one bit in the meeting minutes:

On Mon, Jul 1, 2013 at 3:10 PM, Mo Zanaty (mzanaty) 
<mzanaty@cisco.com>
wrote:
RMCAT Eval Design Team Meeting

Monday, July 1, 2013, 11:00AM New York Time (EDT UTC-4)

(snip)

 - Should RMCAT solution candidates explicitly support weighted fairness? Mandatory, optional, or prohibited?

 - The requirements draft does not mention weighted fairness nor equal-rate fairness, just that fairness is "a hard-to-define term", "a tough question". Need to decide what firmer position the req draft should take, so further drafts (eval, candidates, etc.) have clear reqs.

 - It was noted that in the absence of weighted fairness within RMCAT itself, applications will game multiple RMCATs to achieve weighted fairness.

DTM> Mentions were made about updating Randell's draft to see if weighted fairness should be a general requirement of an RMCAT implementation.

Weighted fairness is requirement F34 in

http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requireme
n
ts-10

... to address this requirement, the "identifying and controlling groups of flows" milestone ended up in the charter. Therefore I think there should be no debate about "do we want to support this?".

The charter says this WG should "Develop a mechanism for identifying 
shared bottlenecks between groups of flows, and means to flexibly 
allocate their rates within the aggregate hitting the shared bottleneck." "Flexibly allocate rate" does not explicitly mean "weighted fairness", at least not to me. I see "weighted fairness" is one of the ways to solve the problem.

When a set of flows are grouped based on common shared bottleneck that group of flows may have same priority or different. Moreover, different applications might have different meaning of priorities and different policies to handle lower priority flows when congestion occurs. Some of them would like to distribute the available bandwidth based on their priorities and some other weights, some might like to kill the lower priority flow before touching the higher priority flows, some might even like to have multiple level of priorities, meaning different preference within the same priority group. Hence dealing with all these variations will be a great challenge. It will need proper APIs between application and RMCAT solution and proper definition of "flexible allocation of rate".

I have the impression that you're over-complicating this.

Regarding RTCWEB req F34, I don't think even RTCWEB WG has clear idea how that will be realized in the end. 

But we should: it was this requirement that motivated the RMCAT charter text that we're discussing here. Hence, at least when RMCAT was conceived, the intention was that this group should take care of this requirement.

Hence, I would like to discuss " means to flexibly allocate rate and how to realize it" before saying "weighted fairness" is the way forward.

"Develop a means to do something" indicates that stuff isn't happening automatically; instead, we're building a tool that lets someone take control. That someone could be one application, or multiple, or the user. We should make it possible for something (or someone) to "flexibly allocate rate". The word "flexibly" stresses that the control should have as few limitations as possible.

So, this sentence really means: "make it possible for someone or something to pretty arbitrarily control the rates of the flows in an aggregate that shares a bottleneck."

Once someone/-thing is in control of the rates, that someone/-thing can realize the policies you describe above. The policies themselves (re-assigning priorities vs. priority groups vs. killing a flow to support the next vs. .....) are nothing to worry about for RMCAT, then, as long as the possibility to assign rates within the aggregate is given. Not sure if "weighted fairness" is the right word for this functionality or not, but anyway, that's what we need.

Until we do so I would suggest that in our simple (the one Micheal Ramalho worked on) fairness test scenario we assume all flows have same priority and ensure RMCAT solution shows some sort of fairness among those flow. My current feeling is that it is very hard to do so.

I'm fine with that, actually. A fair allocation gives the mechanism for flexible rate allocation a starting point. We need that. However, to be able to really be in control of these rates, I think that RTT-independence would be a desirable property. I'm not sure if we should prescribe this because it's asking much, but I think we should recommend it.

Cheers,
Michael

-- 

Zahed

==================================================
ANM ZAHEDUZZAMAN SARKER 

Ericsson AB
Multimedia Technologies
Laboratoriegränd 11
97128 Luleå, Sweden
Phone +46 10 717 37 43
Fax +46 920 996 21
SMS/MMS +46 76 115 37 43
zaheduzzaman.sarker@ericsson.com
www.ericsson.com

==================================================
Michael,

Thanks for your reply. I think you and Zahed were talking past each other.

On the RMCAT design team call, the "weighted fairness topic" came up in the c=
ontext of Case 2 (weighted fairness BETWEEN different RMCAT associations). T=
he "between sessions" topic was initiated by Xiaoqing Zhu (as that is what a=
 NADA does - see her draft for that). I believe that Case 2 was the context b=
ehind Zahed's reply.

=46rom what I understand, your draft deals primarily with Case 1 (within a s=
ingle RMCAT session/association/whatever-we-will-call-it). And I believe tha=
t was the context of your reply.

And now we all agree that our initial work should focus on RMCAT fairness fo=
r flows with equal priority ... and that RTT-fairness is a desirable but not=
-yet-determined-to-be-feasible goal.

Michael Ramalho

PS - Fairness independent of RTT may be attainable, but it would need to be m=
easured on timescales that are many multiples of the RMCAT flow with the lar=
gest RTT. This is because the maximum time rate of change of the BW estimate=
 must be a function of the RTT (feedback is not instantaneous). This is easi=
ly seen in the dynamics of any window-based congestion control (such as TCP)=
. Indeed, "end-to-end capacity" may need to be defined via a bandwidth measu=
re on a similar timescale (this is a shortcoming of many IETF drafts - where=
 they just say "capacity" without even defining it ...  but I digress).

-----Original Message-----
From: Michael Welzl [mailto:michawe@ifi.uio.no]=20
Sent: Friday, July 05, 2013 12:30 PM
To: Michael Ramalho (mramalho)
Cc: Zaheduzzaman Sarker; Dan Weber; Mo Zanaty (mzanaty); rmcat@ietf.org
Subject: Re: [rmcat] Design Team Meeting Minutes & Recording July 1

Hi,

I'll try to summarize in what I think are simpler words (but sticking to SCT=
P terminology):
case 1: priorities WITHIN a single RMCAT association case 2: priorities BETW=
EEN multiple RMCAT associations (which may embed case 1, i.e. one RMCAT asoc=
ation may have multiple flows with priorities between them)

I think we agree that supporting case 1 is a must. Supporting case 2, howeve=
r, is much more difficult, and may not even be a reasonable goal to pursue w=
hen we're at the same time trying to be roughly TCP-compatible and minimize d=
elay. It might be possible to do this in some way, but I would prefer to avo=
id dealing with case 2, I was only concerned with case 1. I do not believe t=
hat anyone expects us to solve case 2.

I see that case 1 may not be what you were concerned with when discussing "w=
eighted fairness", but enabling case 1 with a method akin to the one in our c=
oupled-cc draft still requires that some external entity can set the rate of=
 a flow to a rate that wasn't determined by it. That is a bit unusual and sh=
ould be a part of the tests that people should do with their mechanisms, I t=
hink. Yes, I am sorry for not having brought this up earlier!

Cheers,
Michael

On Jul 5, 2013, at 6:11 PM, "Michael Ramalho (mramalho)" <mramalho@cisco.com> wrote:

Michael & Zahed (mostly),

The thread below is a little rugged ... so let me just comment here at the t=
op ;-).

The RTCWeb requirement F34 (The browser MUST support prioritization of strea=
ms and data) can be taken at least two different ways of importance to RMCAT=
.

The first way is that RMCAT transport should provide an API to the applicati=
on that allows it to "appropriately prioritize" the application traffic prov=
ided to it when it puts that traffic on the wire. I think that will eventual=
ly be a must - although we are still quite far from specifying how that API b=
ehaves as we aren't done at the transport level yet ;-). Obviously, the prio=
ritization of flows within one host is doable with information on that one h=
ost.

The second way applies when ALL FLOWS through a bottleneck are RMCAT flows -=
 and that a given RMCAT association (borrowing SCTP terminology here) could h=
ave multiple RMCAT streams of various priorities within it. Let's say your R=
MCAT association has streams of different priorities. Then you could have a d=
esire  to compete fairly IN PRIORITY with other RMCAT streams of priority fo=
o. That is a MUCH harder requirement. And possibly impossible if your flow i=
s mixing with other existing transports.

Is it your understanding that RTCWeb hopes we  (RMCAT) handle the second cas=
e? And if so, with what desired mechanism (perhaps congestion control rate e=
stimation be a function of the priority value provided to the RMCAT transpor=
t - but that only works with an assumed traffic mix at the bottleneck - whic=
h is unknowable at a given host)?

Thanks for your input ...

Michael Ramalho

-----Original Message-----
From: rmcat-bounces@ietf.org [=
mailto:rmcat-bounces@ietf.org] On Behalf=20
Of Michael Welzl
Sent: Thursday, July 04, 2013 4:14 PM
To: Zaheduzzaman Sarker
Cc: Dan Weber; Mo Zanaty (mzanaty); rmcat@=
ietf.org
Subject: Re: [rmcat] Design Team Meeting Minutes & Recording July 1

On Jul 4, 2013, at 9:06 PM, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> wrote:

Hi,

My comment below.

BR
Zahed
On 2013-07-03 15:41, Michael Welzl wrote:

Hi,

See below a comment about one bit in the meeting minutes:

On Mon, Jul 1, 2013 at 3:10 PM, Mo Zanaty (mzan=
aty)=20
<mzanaty@cisco.com>
wrote:
RMCAT Eval Design Team Meeting

Monday, July 1, 2013, 11:00AM New York Time (EDT UTC-4)

(snip)

 - Should RMCAT solution candidates explicitly s=
upport weighted fairness? Mandatory, optional, or prohibited?

 - The requirements draft does not mention weighted fairness nor equal-rate f=
airness, just that fairness is "a hard-to-define term", "a tough question". N=
eed to decide what firmer position the req draft should take, so further dra=
fts (eval, candidates, etc.) have clear reqs.

 - It was noted that in the absence of weighted fairness within RMCAT itself=
, applications will game multiple RMCATs to achieve weighted fairness.

DTM> Mentions were made about updating Randell's draft to see if weighted=
 fairness should be a general requirement of an RMCAT implementation.

Weighted fairness is requirement F34 in

http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requireme
n
ts-10

... to address this requirement, the "identifying and controlling groups of f=
lows" milestone ended up in the charter. Therefore I think there should be n=
o debate about "do we want to support this?".

The charter says this WG should "Develop a mechanis=
m for identifying=20
shared bottlenecks between groups of flows, and means to flexibly=20
allocate their rates within the aggregate hitting the shared bottleneck." "Fl=
exibly allocate rate" does not explicitly mean "weighted fairness", at least=
 not to me. I see "weighted fairness" is one of the ways to solve the proble=
m.

When a set of flows are grouped based on common shared bottleneck that group=
 of flows may have same priority or different. Moreover, different applicati=
ons might have different meaning of priorities and different policies to han=
dle lower priority flows when congestion occurs. Some of them would like to d=
istribute the available bandwidth based on their priorities and some other w=
eights, some might like to kill the lower priority flow before touching the h=
igher priority flows, some might even like to have multiple level of priorit=
ies, meaning different preference within the same priority group. Hence deal=
ing with all these variations will be a great challenge. It will need proper=
 APIs between application and RMCAT solution and proper definition of "flexi=
ble allocation of rate".

I have the impression that you're over-complicating t=
his.

Regarding RTCWEB req F34, I don't think even RTCWEB=
 WG has clear idea how that will be realized in the end.=20

But we should: it was this requirement that motivated=
 the RMCAT charter text that we're discussing here. Hence, at least when RMC=
AT was conceived, the intention was that this group should take care of this=
 requirement.

Hence, I would like to discuss " means to flexibly a=
llocate rate and how to realize it" before saying "weighted fairness" is the=
 way forward.

"Develop a means to do something" indicates that stuf=
f isn't happening automatically; instead, we're building a tool that lets so=
meone take control. That someone could be one application, or multiple, or t=
he user. We should make it possible for something (or someone) to "flexibly a=
llocate rate". The word "flexibly" stresses that the control should have as f=
ew limitations as possible.

So, this sentence really means: "make it possible for someone or something t=
o pretty arbitrarily control the rates of the flows in an aggregate that sha=
res a bottleneck."

Once someone/-thing is in control of the rates, that someone/-thing can real=
ize the policies you describe above. The policies themselves (re-assigning p=
riorities vs. priority groups vs. killing a flow to support the next vs. ...=
..) are nothing to worry about for RMCAT, then, as long as the possibility t=
o assign rates within the aggregate is given. Not sure if "weighted fairness=
" is the right word for this functionality or not, but anyway, that's what w=
e need.

Until we do so I would suggest that in our simple (=
the one Micheal Ramalho worked on) fairness test scenario we assume all flow=
s have same priority and ensure RMCAT solution shows some sort of fairness a=
mong those flow. My current feeling is that it is very hard to do so.

I'm fine with that, actually. A fair allocation gives=
 the mechanism for flexible rate allocation a starting point. We need that. H=
owever, to be able to really be in control of these rates, I think that RTT-=
independence would be a desirable property. I'm not sure if we should prescr=
ibe this because it's asking much, but I think we should recommend it.

Cheers,
Michael

--=20

Zahed

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ANM ZAHEDUZZAMAN SARKER=20

Ericsson AB
Multimedia Technologies
Laboratoriegr=C3=A4nd 11
97128 Lule=C3=A5, Sweden
Phone +46 10 717 37 43
Fax +46 920 996 21
SMS/MMS +46 76 115 37 43
zaheduzzaman.sarker@eric=
sson.com
www.ericsson.com

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 =20