From harald@alvestrand.no Thu Jan 2 16:19:10 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB071ACC84 for ; Thu, 2 Jan 2014 16:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.263 X-Spam-Level: X-Spam-Status: No, score=0.263 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16ISmw131fQG for ; Thu, 2 Jan 2014 16:19:05 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [IPv6:2001:700:1:2:213:72ff:fe0b:80d8]) by ietfa.amsl.com (Postfix) with ESMTP id AE85D1AC43F for ; Thu, 2 Jan 2014 16:19:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6543539E0D2 for ; Fri, 3 Jan 2014 01:19:02 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2TEXijIMOne for ; Fri, 3 Jan 2014 01:18:59 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:60c4:879c:21ee:c898] (unknown [IPv6:2001:470:de0a:27:60c4:879c:21ee:c898]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7529339E09F for ; Fri, 3 Jan 2014 01:18:59 +0100 (CET) Message-ID: <52C60213.9000401@alvestrand.no> Date: Fri, 03 Jan 2014 01:19:31 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rmcat@ietf.org References: <52C17E9F.8060703@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000509080804000105080300" Subject: Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 00:19:11 -0000 This is a multi-part message in MIME format. --------------000509080804000105080300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/31/2013 07:37 AM, Dave Taht wrote: > On Mon, Dec 30, 2013 at 6:09 AM, Harald Alvestrand wrote: >> Dave, this is interesting .... I think characterizing what the connection >> between type-of-traffic and applicable congestion is should be an rmcat >> issue, but may feed back into RTCWEB and even MMUSIC - so I'm sending this >> to rmcat only. >> >> >> >> On 12/30/2013 01:02 AM, Dave Taht wrote: >>> I finally had a chance to read over >>> >>> http://tools.ietf.org/html/draft-ietf-rmcat-cc-requirements-01 >>> >>> and also work at reproducing some of the difficulties present in the >>> current implementation of chrome in light of the two papers presented >>> at the last ietf on google congestion control. I went through tons of >>> tests and packet captures that pretty much reproduced the legion of >>> problems documented in >>> >>> >>> https://speakerdeck.com/vr000m/evaluating-googles-congestion-control-for-webrtc >>> and the other paper presented at ietf... >>> >>> and also fed webrtc traffic through the fq_codel and pie queue >>> management systems (with pretty good results). I have tons of captures >>> from each experiment if anyone wants them. >>> >>> So, I have some comments on this requirements document. (I'm new to >>> paying attention on rmcat, so a few of my questions are probably >>> answered by some document I haven't read yet. Steers appreciated. for >>> all I know I'm on the wrong mailing lists too. Sorry) >>> >>> In particular, the flows I was looking at multiplexed voice and video >>> on the same 5 tuple. I am curious as to the justification for this, as >>> voice (without silence suppression) is isochronous and video is not. >>> (is silence suppression used in webrtc?) >> >> This is a curious statement - what characteristic are you thinking about >> when you say that voice is "isochronous" and video is not? >> Both of them are produced one time-frame at a time, and both of them cause >> irritation at the receiver when the frames are displayed in anything but the >> same cadence. > On a per packet level, voice is typically one packet ranging in size > from 110 bytes to 300 every 10 or 20ms. (the opus codec goes down to > 2.5ms) Video, in comparison, consists of a variable number of (often) > many packets depending on encoding, subframes, etc. > > So from this viewpoint voice can be isochronous (lacking silence > suppression), and video is not. OK, so synchronous production of single packets is isochronous, while synchronous production of group of packets is not. I don't mind, as long as we agree what we're saying :-) > >> I think the irritation from jitter on voice is quite a bit higher than on >> video, but stuttering video isn't a good thing either. > jitter and loss on voice is often quite annoying. On music it's intolerable. > > On video, I would not use the word "stuttering" which implies a > max-headroom sort of effect. Partial corruption of the output, blocky > output, etc are closer to words I would use. Yup, those are more irritating artifacts in video than distortions in time. In fact, most of the time, the most irritating time-related aspect of video is most often loss of synchronization with the audio. > >>> To me, multiplexing these two very different flows on the same ports >>> is not a good idea except under extreme port pressure, and not useful >>> in ipv6 or in non-natted environments at all. Even in a natted >>> environment, saving a single port is a false savings as (for example) >>> dns lookups punch dozens of holes through nat on a regular basis. >>> >>> Requiring that in most or all cases these two flow types be on unique >>> 5 tuples would give smarter queue management techniques on routers >>> (like sfq, or sqf (deployed at FT), or fq_codel (deployed at >>> free.fr)), a fighting chance. In particular it gives voice much higher >>> probability for drop-and-delay free behavior, and analyzing the delta >>> in drops and delay between a separate voice tuple and video tuple >>> could provide insight as to the congestion in the system. >> How does this effect happen? > Could you be more specific? > >> In particular, does the separation of flows itself create lower loss >> probability for voice, or are you thinking of systems where the network >> elements "know" what the flows contain? > In nearly any packet scheduled system (drr, sfq,sqf, fq_codel, etc), > the separation of flows on a 5 tuple will result in (much) less delay, > jitter and loss for the lower rate flows. With sqf and fq_codel, if > the rate is low enough there will be near zero queuing delay, jitter > and loss on many workloads. I think you answered my previous question here - what you're saying is that when sfq etc deals with several flows, it will prioritize delivery of packets in the smaller flows ahead of delivery of packets in the larger flows. Which, if the audio flow is smaller than the video flow (true almost all the time), will have the effect of causing video corruption to happen before audio corruption. > > I try to encourage people to just try it to get a feel for what > happens. openwrt, cerowrt, any modern linux for all of the above, > cisco routers do drr, many dsl devices do sfq or sqf in their > firmware.... > > separation of flows does nothing terrible useful on a strict drop tail > system, but no harm either. > >> What about multiplexing between different flows of the same media type? > Good question. There are many things I don't understand about webrtc's > intended audience. > > What excites me most about it is the ability to do in-the-building > videoconferences without having to go over the internet for them. As > for going over the internet... I think the cable industry is too > broken (currently) for any e2e congestion control algorithm to work at > all with serious cross traffic, with up and downlinks having 2 or more > seconds of buffering each. (unless fixed by one of the algorithms > above in a 3rd party router) FIOS and DSL users have a fighting > chance, 3g and LTE less so, and wifi needs some serious work. > > So at the moment I'd like to be addressing the fixable e2e problems in > gcc (it can't even compete with itself!) and wanted to be able to > break things out on tuples to look at the data... > > before drawing any conclusions on how to multiplex video flows. > > My gut tells me you want one tuple per voice and per video flow, AND > to manage their congestion indicators together, but depending on the > level of statistical multiplexing of the video flows they could go on > a single tuple. That looks approximately sensible to me too. I spent quite a bit of time arguing in AVT* that setting this kind of rule in the structure of the signalling was a grave architectural mistake (which was one of the impetuses for the BUNDLE work in the first place); that we needed to be free to experiment with this to figure out what worked, and change that in deployment, not in specs. From what you write above, it seems that one would wish to harness the network's (new) tendency to discrimiate against high-volume flows in order to get audio through with near zero loss - but I don't want to embed that assumption into the application; I'd much prefer that the application could make an explicit decision on what's important to it, and that ways be found to let the network respect that wish. Which may lead us back very close to the guidelines that were enshrined in RTP and SDP specifications 20 years ago .... but then again, it might not. [This looks so good as the end statement of the message, so it seems a pity that I need to add some specifics below. Other people commenting .. feel free to delete below this line.] > >>> In current implementations, is it possible to force flows onto >>> different tuples? >> >> Absolutely - just don't negotiate bundling. > Pointer to a working example? People have been doing this by editing out the line in the SDP that starts off "a=group:BUNDLE" More elegant solutions should be deployed. > > keep hoping there's working ipv6 code out there too, getting the stun > and turn stuff out of the loop long enough to look at simpler cases. I think you're already copied on https://code.google.com/p/webrtc/issues/detail?id=1406 > >>> What are the other flaws in suggesting or requiring >>> a different tuple? >> >> >>> (note I'm not suggesting bulk data traffic get unique 5 tuples per flow) >> >> I wouldn't either. >> In current deployments, it's multiplexed with the media traffic on the same >> 5-tuple too - what would you suggest advising it to be bundled with, and >> why? > My understanding of the use case for that is that it is for p2p file > transfer. Given how prone to failure setup has been for this in other > protocols it seems to make some sense to bundle it on the video > tuple... > >> (dropping the rest of the message - this should be enough for one thread) >> > > --------------000509080804000105080300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12/31/2013 07:37 AM, Dave Taht wrote:
On Mon, Dec 30, 2013 at 6:09 AM, Harald Alvestrand <harald@alvestrand.no> wrote:

Dave, this is interesting .... I think characterizing what the connection
between type-of-traffic and applicable congestion is should be an rmcat
issue, but may feed back into RTCWEB and even MMUSIC - so I'm sending this
to rmcat only.



On 12/30/2013 01:02 AM, Dave Taht wrote:

I finally had a chance to read over

http://tools.ietf.org/html/draft-ietf-rmcat-cc-requirements-01

and also work at reproducing some of the difficulties present in the
current implementation of chrome in light of the two papers presented
at the last ietf on google congestion control. I went through tons of
tests and packet captures that pretty much reproduced the legion of
problems documented in


https://speakerdeck.com/vr000m/evaluating-googles-congestion-control-for-webrtc
and the other paper presented at ietf...

and also fed webrtc traffic through the fq_codel and pie queue
management systems (with pretty good results). I have tons of captures
from each experiment if anyone wants them.

So, I have some comments on this requirements document. (I'm new to
paying attention on rmcat, so a few of my questions are probably
answered by some document I haven't read yet. Steers appreciated. for
all I know I'm on the wrong mailing lists too. Sorry)

In particular, the flows I was looking at multiplexed voice and video
on the same 5 tuple. I am curious as to the justification for this, as
voice (without silence suppression) is isochronous and video is not.
(is silence suppression used in webrtc?)


This is a curious statement - what characteristic are you thinking about
when you say that voice is "isochronous" and video is not?
Both of them are produced one time-frame at a time, and both of them cause
irritation at the receiver when the frames are displayed in anything but the
same cadence.

On a per packet level, voice is typically one packet ranging in size
from 110 bytes to 300 every 10 or 20ms. (the opus codec goes down to
2.5ms) Video, in comparison, consists of a variable number of (often)
many packets depending on encoding, subframes, etc.

So from this viewpoint voice can be isochronous (lacking silence
suppression), and video is not.

OK, so synchronous production of single packets is isochronous, while synchronous production of group of packets is not. I don't mind, as long as we agree what we're saying :-)



I think the irritation from jitter on voice is quite a bit higher than on
video, but stuttering video isn't a good thing either.

jitter and loss on voice is often quite annoying. On music it's intolerable.

On video, I would not use the word "stuttering" which implies a
max-headroom sort of effect. Partial corruption of the output, blocky
output, etc are closer to words I would use.

Yup, those are more irritating artifacts in video than distortions in time.
In fact, most of the time, the most irritating time-related aspect of video is most often loss of synchronization with the audio.





        

          
To me, multiplexing these two very different flows on the same ports
is not a good idea except under extreme port pressure, and not useful
in ipv6 or in non-natted environments at all. Even in a natted
environment, saving a single port is a false savings as (for example)
dns lookups punch dozens of holes through nat on a regular basis.

Requiring that in most or all cases these two flow types be on unique
5 tuples would give smarter queue management techniques on routers
(like sfq, or sqf (deployed at FT), or fq_codel (deployed at
free.fr)), a fighting chance. In particular it gives voice much higher
probability for drop-and-delay free behavior, and analyzing the delta
in drops and delay between a separate voice tuple and video tuple
could provide insight as to the congestion in the system.


        

        
How does this effect happen?


      

      
Could you be more specific?



      

        
In particular, does the separation of flows itself create lower loss
probability for voice, or are you thinking of systems where the network
elements "know" what the flows contain?


      

      
In nearly any packet scheduled system (drr, sfq,sqf, fq_codel, etc),
the separation of flows on a 5 tuple will result in (much) less delay,
jitter and loss for the lower rate flows. With sqf and fq_codel, if
the rate is low enough there will be near zero queuing delay, jitter
and loss on many workloads.

    

    

    I think you answered my previous question here - what you're saying
    is that when sfq etc deals with several flows, it will prioritize
    delivery of packets in the smaller flows ahead of delivery of
    packets in the larger flows.

    

    Which, if the audio flow is smaller than the video flow (true almost
    all the time), will have the effect of causing video corruption to
    happen before audio corruption.

    

    

      

I try to encourage people to just try it to get a feel for what
happens. openwrt, cerowrt, any modern linux for all of the above,
cisco routers do drr, many dsl devices do sfq or sqf in their
firmware....

separation of flows does nothing terrible useful on a strict drop tail
system, but no harm either.



      

        
What about multiplexing between different flows of the same media type?


      

      
Good question. There are many things I don't understand about webrtc's
intended audience.

What excites me most about it is the ability to do in-the-building
videoconferences without having to go over the internet for them.  As
for going over the internet... I think the cable industry is too
broken (currently) for any e2e congestion control algorithm to work at
all with serious cross traffic, with up and downlinks having 2 or more
seconds of buffering each. (unless fixed by one of the algorithms
above in a 3rd party router) FIOS and DSL users have a fighting
chance, 3g and LTE less so, and wifi needs some serious work.

So at the moment I'd like to be addressing the fixable e2e problems in
gcc (it can't even compete with itself!) and wanted to be able to
break things out on tuples to look at the data...

before drawing any conclusions on how to multiplex video flows.

My gut tells me you want one tuple per voice and per video flow, AND
to manage their congestion indicators together, but depending on the
level of statistical multiplexing of the video flows they could go on
a single tuple.

    

    

    That looks approximately sensible to me too.

    

    I spent quite a bit of time arguing in AVT* that setting this kind
    of rule in the structure of the signalling was a grave architectural
    mistake (which was one of the impetuses for the BUNDLE work in the
    first place); that we needed to be free to experiment with this to
    figure out what worked, and change that in deployment, not in specs.

    

    From what you write above, it seems that one would wish to harness
    the network's (new) tendency to discrimiate against high-volume
    flows in order to get audio through with near zero loss - but I
    don't want to embed that assumption into the application; I'd much
    prefer that the application could make an explicit decision on
    what's important to it, and that ways be found to let the network
    respect that wish.

    

    Which may lead us back very close to the guidelines that were
    enshrined in RTP and SDP specifications 20 years ago .... but then
    again, it might not.

    

    [This looks so good as the end statement of the message, so it seems
    a pity that I need to add some specifics below. Other people
    commenting .. feel free to delete below this line.]

    

    

    

      



      

        

          
In current implementations, is it possible to force flows onto
different tuples?


        

        

Absolutely - just don't negotiate bundling.


      

      
Pointer to a working example?

    

    

    People have been doing this by editing out the line in the SDP that
    starts off

    "a=group:BUNDLE"

    

    More elegant solutions should be deployed.

    

    

      

keep hoping there's working ipv6 code out there too, getting the stun
and turn stuff out of the loop long enough to look at simpler cases.

    

    

    I think you're already copied on
    
    https://code.google.com/p/webrtc/issues/detail?id=1406

    

    

    

      



      

        

        

          
  What are the other flaws in suggesting or requiring
a different tuple?


        

        




        

          
(note I'm not suggesting bulk data traffic get unique 5 tuples per flow)


        

        

I wouldn't either.
In current deployments, it's multiplexed with the media traffic on the same
5-tuple too - what would you suggest advising it to be bundled with, and
why?


      

      
My understanding of the use case for that is that it is for p2p file
transfer. Given how prone to failure setup has been for this in other
protocols it seems to make some sense to bundle it on the video
tuple...



      

        
(dropping the rest of the message - this should be enough for one thread)



      

      




    

    

  


--------------000509080804000105080300--

From michawe@ifi.uio.no  Fri Jan  3 00:25:39 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56B21ADF38 for ; Fri,  3 Jan 2014 00:25:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCdNZlXKjDXo for ; Fri,  3 Jan 2014 00:25:36 -0800 (PST)
Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1831ADF33 for ; Fri,  3 Jan 2014 00:25:35 -0800 (PST)
Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Vz04N-0005XK-OT; Fri, 03 Jan 2014 09:25:27 +0100
Received: from 089144207158.atnat0016.highway.bob.at ([89.144.207.158] helo=[192.168.1.2]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1Vz04D-0000sz-LL; Fri, 03 Jan 2014 09:25:27 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_0F9C4061-28DD-45D6-994A-BE17E072B9CF"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Michael Welzl 
In-Reply-To: <52C60213.9000401@alvestrand.no>
Date: Fri, 3 Jan 2014 09:25:13 +0100
Message-Id: 
References:  <52C17E9F.8060703@alvestrand.no>  <52C60213.9000401@alvestrand.no>
To: Harald Alvestrand 
X-Mailer: Apple Mail (2.1510)
X-UiO-SPF-Received: 
X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 6 sum rcpts/h 13 sum msgs/h 8 total rcpts 11214 max rcpts/h 44 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 07B0C44D4F09857DE90FB1B3F7C8DB2015DE2BA1
X-UiO-SPAM-Test: remote_host: 89.144.207.158 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 6 total 16 max/h 6 blacklist 0 greylist 0 ratelimit 0
Cc: rmcat@ietf.org
Subject: Re: [rmcat] 5 tuples and rmcat-cc-requirements-01
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Jan 2014 08:25:40 -0000

--Apple-Mail=_0F9C4061-28DD-45D6-994A-BE17E072B9CF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

On 3. jan. 2014, at 01:19, Harald Alvestrand  =
wrote:

> On 12/31/2013 07:37 AM, Dave Taht wrote:
>> On Mon, Dec 30, 2013 at 6:09 AM, Harald Alvestrand =
 wrote:

[snip]

>> My gut tells me you want one tuple per voice and per video flow, AND
>> to manage their congestion indicators together, but depending on the
>> level of statistical multiplexing of the video flows they could go on
>> a single tuple.
>=20
> That looks approximately sensible to me too.

Not so much to me. Dave's gut seems to argue for separate treatment of =
audio and video in the network - what for? To protect them from each =
other, because the sending application doesn't know what it's doing?


> I spent quite a bit of time arguing in AVT* that setting this kind of =
rule in the structure of the signalling was a grave architectural =
mistake (which was one of the impetuses for the BUNDLE work in the first =
place); that we needed to be free to experiment with this to figure out =
what worked, and change that in deployment, not in specs.
>=20
> =46rom what you write above, it seems that one would wish to harness =
the network's (new) tendency to discrimiate against high-volume flows in =
order to get audio through with near zero loss - but I don't want to =
embed that assumption into the application; I'd much prefer that the =
application could make an explicit decision on what's important to it, =
and that ways be found to let the network respect that wish.

+1.
Separating tuples can help to let the network protect a flow against =
*any* other flow, but for prioritization between flows coming from the =
same application, you should be much better off with joint congestion =
management, where you have 100% control over priorities and get other =
benefits too. My argument is: "send stuff into the network the right way =
rather than hoping for the network to correct your mistakes."


> Which may lead us back very close to the guidelines that were =
enshrined in RTP and SDP specifications 20 years ago .... but then =
again, it might not.


Cheers,
Michael


--Apple-Mail=_0F9C4061-28DD-45D6-994A-BE17E072B9CF
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=iso-8859-1


On 3. jan. 2014, at 01:19, Harald Alvestrand <harald@alvestrand.no> wrote:


  
    
  
  

    
On 12/31/2013 07:37 AM, Dave Taht
      wrote:

    

    

      
On Mon, Dec 30, 2013 at 6:09 AM, Harald Alvestrand <harald@alvestrand.no> wrote:

[snip]

My gut tells me you want one tuple per voice and per video flow, AND
to manage their congestion indicators together, but depending on the
level of statistical multiplexing of the video flows they could go on
a single tuple.

    

    

    That looks approximately sensible to me too.

Not so much to me. Dave's gut seems to argue for separate treatment of audio and video in the network - what for? To protect them from each other, because the sending application doesn't know what it's doing?



    
    I spent quite a bit of time arguing in AVT* that setting this kind
    of rule in the structure of the signalling was a grave architectural
    mistake (which was one of the impetuses for the BUNDLE work in the
    first place); that we needed to be free to experiment with this to
    figure out what worked, and change that in deployment, not in specs.

    

    From what you write above, it seems that one would wish to harness
    the network's (new) tendency to discrimiate against high-volume
    flows in order to get audio through with near zero loss - but I
    don't want to embed that assumption into the application; I'd much
    prefer that the application could make an explicit decision on
    what's important to it, and that ways be found to let the network
    respect that wish.

+1.
Separating tuples can help to let the network protect a flow against *any* other flow, but for prioritization between flows coming from the same application, you should be much better off with joint congestion management, where you have 100% control over priorities and get other benefits too. My argument is: "send stuff into the network the right way rather than hoping for the network to correct your mistakes."



    
    Which may lead us back very close to the guidelines that were
    enshrined in RTP and SDP specifications 20 years ago .... but then
    again, it might not.


Cheers,
Michael


--Apple-Mail=_0F9C4061-28DD-45D6-994A-BE17E072B9CF--

From dave.taht@gmail.com  Fri Jan  3 20:18:13 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEF81A1F06 for ; Fri,  3 Jan 2014 20:18:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.698
X-Spam-Level: ****
X-Spam-Status: No, score=4.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_STOCK2=3.988, SPF_PASS=-0.001, T_FRT_STOCK2=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zZe_jPji2Nh for ; Fri,  3 Jan 2014 20:18:10 -0800 (PST)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0F71A16F0 for ; Fri,  3 Jan 2014 20:18:10 -0800 (PST)
Received: by mail-wi0-f178.google.com with SMTP id bz8so1109102wib.17 for ; Fri, 03 Jan 2014 20:18:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZNbNIsyGhbmM6xTtz9/pMem+XH4sdM/ZID73PYk0qcU=; b=u6kf9Lo0Iu+nbqxmMjnrzFEvwbrtxR70Qa7wp/C+BKBWGIQIHTqBMWfJMzU3bSUqjD Ti6oCMrxnBaf4sUBFidlwMzEj5c0CaCn3B3vt703BwzXBa8CQ7e6TBV7QWRCzXy2IOej lWeZN6IKyNhZSFVe350Ss5ZBcTDWNbIKp61gPxTvQRxr6yBimvsOu+5Tr8FcYC0n6yvV e1XQTWtlMOTsTpnRjNtinyHnpiOvidZF+SBgDpR65j1hOBV0VteKozMVaNfhAwWUyfmu +fXRL/ADHsibCVE2WwSvjLNp6KrQ2pxvz9OQfPJJ7ysrk/MJbffAtHzhheCg7a7kFz6p V3lg==
MIME-Version: 1.0
X-Received: by 10.180.90.230 with SMTP id bz6mr4354678wib.17.1388809082264; Fri, 03 Jan 2014 20:18:02 -0800 (PST)
Received: by 10.217.123.69 with HTTP; Fri, 3 Jan 2014 20:18:02 -0800 (PST)
In-Reply-To: 
References:  <52C17E9F.8060703@alvestrand.no>  <52C60213.9000401@alvestrand.no> 
Date: Fri, 3 Jan 2014 23:18:02 -0500
Message-ID: 
From: Dave Taht 
To: Michael Welzl 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Harald Alvestrand , "rmcat@ietf.org" 
Subject: Re: [rmcat] 5 tuples and rmcat-cc-requirements-01
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 04 Jan 2014 04:18:13 -0000

On Fri, Jan 3, 2014 at 3:25 AM, Michael Welzl  wrote:
> On 3. jan. 2014, at 01:19, Harald Alvestrand  wrote=
:
>
> On 12/31/2013 07:37 AM, Dave Taht wrote:
>
> On Mon, Dec 30, 2013 at 6:09 AM, Harald Alvestrand 
> wrote:
>
>
> [snip]
>
> My gut tells me you want one tuple per voice and per video flow, AND
> to manage their congestion indicators together, but depending on the
> level of statistical multiplexing of the video flows they could go on
> a single tuple.
>
>
> That looks approximately sensible to me too.
>
>
> Not so much to me. Dave's gut seems to argue for separate treatment of au=
dio
> and video in the network - what for? To protect them from each other,
> because the sending application doesn't know what it's doing?

0) audio behaves way differently than video, and should be differentiated.
I personally care not a whit if my video goes to hell once in a while. I ca=
re
a lot if my audio does. Videoconferences do contain a lot of visual informa=
tion
but audio, despite being truly tiny relatively, is critical.

1) To differentiate them from other flows on the network. The sending
application
can't know what those flows are doing.

2) To make analysis easier from tools like wireshark (my immediate need).
What my gut says and what experiment shows is often very different. I
can see some problems with splitting tuples like this, like adding an
extra system call every 10ms or so, and having to explicitly be aware of
joint time stamps from two streams, but I think they are small problems
relative to the potential benefits.

3) To take advantage, where possible, of different scheduling and classific=
ation
techniques in the network. A strict drop tail or AQM system won't be
affected by adding in this support, although I foresee better mixing on the
endpoints as being a benefit across any network technology. I'd like
to be fiddling with ECN as well.

What I think I see now is enormous bursts of video and audio on periods
far greater than 10ms in the data I have, with bad collapses, bursty packet
loss, and lousy recovery time. So I'm poking at sources...

> I spent quite a bit of time arguing in AVT* that setting this kind of rul=
e
> in the structure of the signalling was a grave architectural mistake (whi=
ch
> was one of the impetuses for the BUNDLE work in the first place); that we
> needed to be free to experiment with this to figure out what worked, and
> change that in deployment, not in specs.

I am in part merely talking about stuff that worked in the 90s and 00s.

I wasn't paying attention whenever this discussion took place. link?

> From what you write above, it seems that one would wish to harness the
> network's (new) tendency to discrimiate against high-volume flows in orde=
r

Not "new". drr and weighted red were widely deployed in the 90s, and so far
 as I know still deployed today. free.fr deployed sfq in 2005, and FT
has specified sqf
for nearly that long. Most ISPs are reticent about their secret sauce, and =
there
are several others whose methods of AQM and packet scheduling I cannot
talk to. Wondershaper came out in 2002 and many other packet scheduling
and qos systems followed.

I only recently learned that free.fr adopted fq_codel summer 2012, for
example. I may end up using their deployed system (which also
does 3 tiers of service classification) for a best practices document.

Aside: I recently ranted about what's wrong in wondershaper today, here:

http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die

...

I wish more data was available.

Despite pushing the major measurement toolmakers (netanalyzr,
samknows, etc) to measure bufferbloat, and detect scheduling and aqm,
they still don't, and tools like shaperprobe aren't effective either. There
is much work to be done in the testing arena.

Wifi uses 4 levels of classification in 802.11e which in linux at least is
mapped to CS0 through CS7.

> to get audio through with near zero loss - but I don't want to embed that

I'd like to see it get through with near zero jitter, delay, and loss in
roughly that order. non-bursty loss is easily compensated for.

> assumption into the application; I'd much prefer that the application cou=
ld
> make an explicit decision on what's important to it, and that ways be fou=
nd
> to let the network respect that wish.

I would like something of the inverse, I'd like the presence of packet
scheduling to
be detected by the application and utilized if seen, by correlating the
differences in behavior between a high rate and a low rate flow in particul=
ar.

I'm also very interested in determining the effects of the leading
AQM and packet scheduling candidates on videoconferencing in general.

At the moment, however, what I'd mostly like is the ability to experiment.
Building chromium has thus far been no fun, although I think great strides
could be made with only a few dozen lines of added code.

> +1.
> Separating tuples can help to let the network protect a flow against *any=
*
> other flow, but for prioritization between flows coming from the same
> application, you should be much better off with joint congestion manageme=
nt,
> where you have 100% control over priorities and get other benefits too. M=
y
> argument is: "send stuff into the network the right way rather than hopin=
g
> for the network to correct your mistakes."

I think it is best to do both.

I think it is incorrect to use the word prioritization when it comes
to the effects of packet scheduling. When I think of prioritization
I think of using diffserv or dpi to classify packets into bins. When
I think of scheduling, fair queuing, flow queueing, etc.,
I think of identifying flows and doing better mixing between them;
of turning packets back into packets again.

Certainly, folk are discovering that sending large bursts into the
network is a bad idea. See for example the recent "Bullet Train"
paper.

http://conferences.sigcomm.org/co-next/2013/program/p133.pdf

Although I feel adding AQM and packet scheduling are necessary for
the current and next generation of nearly all network technologies,
I am tracking improvements in how we do server and client side
stuff closely also.

An endpoint result of all the back and forth about aqm, packet scheduling,
burstyness, and bufferbloat over the last 3 years has been huge reductions =
in
buffering across the linux stack, a switch to a more pull
model for tcp in particular gradually between linux 3.3 and 3.12,
and the recent addition of a paced fq packet scheduler in 3.12
which is yielding quite excellent results for tcp and video
streams thus far.

http://thread.gmane.org/gmane.linux.network/281023

I think it is probable that this will evolve to become a default qdisc
for linux in general, and that applications should be
twidding with the pacing value in order to get good results
out of the OS on granularities lower than 10ms.

(does anyone know the new setsockopt for this?)

That said, certain kinds of layer 2 technologies (wifi, cable,
3g) *require* bursts in order to function at their highest bandwidth,
and we've trimmed so much fat from Linux in particular that
we're at having to fix device drivers and devices again:

http://www.spinics.net/lists/stable-commits/msg30001.html

So yes, I strongly support good mixing from the application level
and for it to be as self aware as possible of its total impact on the
network.

But: although web browsers are complex and for many users
their entire OS (sigh), there is not enough information about
the hosts's other applications, the network and all the devices
held there to do all the job, thus giving the network more
information about flows in general is a good idea.

And I also strongly encourage experimentation with this stuff.
Me being me, I designed a bunch of experiments, emulated
every technology I could (DSL, cable, wifi, ethernet),
got a lot of data, started looking at captures long before
I started looking at source code and started raising questions
here on rmcat. I figure that's backwards from how most
people operate.


> Which may lead us back very close to the guidelines that were enshrined i=
n
> RTP and SDP specifications 20 years ago .... but then again, it might not=
.

Cite? I still dimly remember an internet that ran on more ports than 53, 22=
,
80 and 443. I remember when sip ran on a specific port and RTP was
constrained to a specific port range. The fomer seemed a good idea,
the latter didn't work out so well in the post-nat era.

>
>
>
> Cheers,
> Michael
>



--=20
Dave T=E4ht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.=
html

From michawe@ifi.uio.no  Sat Jan  4 02:28:51 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324BC1ADDD0 for ; Sat,  4 Jan 2014 02:28:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.539
X-Spam-Level: 
X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVIUhttrk1bQ for ; Sat,  4 Jan 2014 02:28:48 -0800 (PST)
Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1551ADDCA for ; Sat,  4 Jan 2014 02:28:47 -0800 (PST)
Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VzOT8-0003Sp-6M; Sat, 04 Jan 2014 11:28:38 +0100
Received: from 089144207158.atnat0016.highway.bob.at ([89.144.207.158] helo=[192.168.1.2]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VzOT5-0001vV-2a; Sat, 04 Jan 2014 11:28:38 +0100
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Michael Welzl 
In-Reply-To: 
Date: Sat, 4 Jan 2014 11:28:29 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <07E05385-225C-4CD9-868C-E86992447BDD@ifi.uio.no>
References:  <52C17E9F.8060703@alvestrand.no>  <52C60213.9000401@alvestrand.no>  
To: Dave Taht 
X-Mailer: Apple Mail (2.1510)
X-UiO-SPF-Received: 
X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 4 sum msgs/h 1 total rcpts 11228 max rcpts/h 44 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 3B383FEE6F590942F2E73190EB491603C9ECDD7E
X-UiO-SPAM-Test: remote_host: 89.144.207.158 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 25 max/h 7 blacklist 0 greylist 0 ratelimit 0
Cc: Harald Alvestrand , "rmcat@ietf.org" 
Subject: Re: [rmcat] 5 tuples and rmcat-cc-requirements-01
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 04 Jan 2014 10:28:51 -0000

Hi,

You answer both Harald and me in this email; I can't respond to the =
parts where you address Harald, and so I'll just cut some stuff away =
below.


On 4. jan. 2014, at 05:18, Dave Taht  wrote:

> On Fri, Jan 3, 2014 at 3:25 AM, Michael Welzl  =
wrote:
>> On 3. jan. 2014, at 01:19, Harald Alvestrand  =
wrote:
>>=20

[snip]


>> Not so much to me. Dave's gut seems to argue for separate treatment =
of audio
>> and video in the network - what for? To protect them from each other,
>> because the sending application doesn't know what it's doing?
>=20
> 0) audio behaves way differently than video, and should be =
differentiated.
> I personally care not a whit if my video goes to hell once in a while. =
I care
> a lot if my audio does. Videoconferences do contain a lot of visual =
information
> but audio, despite being truly tiny relatively, is critical.

Tell this to an owner of website that offers WebRTC-supported striptease =
shows  :-)
My point being: I agree that you describe a common requirement, but this =
decision should really be up to the application designer (via =
prioritiziation, via the JS API).


> 1) To differentiate them from other flows on the network. The sending
> application
> can't know what those flows are doing.

I don't think we need this.

Case 1: consider two RMCAT applications (browsers doing WebRTC) talking =
to each other across one bottleneck link. If you multiplex flows, =
irrespective of what they are, onto a UDP 5-tuple, you shouldn't need =
any help from the network: you're in complete control over priorities on =
the sender side, and you have only one bottleneck, i.e. something that =
acts like a single congestion controller should give you the best =
behavior. Remember that we're envisioning a delay-based cc. here that =
minimizes queuing delay anyway. In such a setting, I can't see how it =
would help to use different tuples for audio and video so that e.g. =
fq_codel could separate them.

Case 2: consider the same scenario, but with other flows on the =
bottleneck that recklessly push up the queue. Then, if you have only one =
common tuple for video and audio, e.g. sfq is going to give this one =
tuple one bin, and one queue, and we're back at what I described for =
case 1 -- separating them would only help to protect the browser's own =
audio from the browser's own video by putting them in different bins.

You mentioned that you'd like to do both, help from the network side =
*and* from within the application by coupling the congestion controls. =
Why, how? You might end up with the sender prioritizing flows in one way =
and the network working against that with sfq. I'd say that we should =
rather try to prevent sfq from doing its job on the sub-flows of an =
rtcweb application. This is not at all to say that fq_codel is a bad =
thing! It's great if it protects rtcweb traffic from everything else - =
but I think that letting it operate on rtcweb sub-flows could give us a =
behavior that we don't want, for no real gain. The fairness of e.g. sfq =
may be inappropriate for individual rtcweb flows (it may go against what =
the person writing the JS app wanted), and the potential delay benefit =
should pretty much disappear if the common congestion control is =
designed to minimize queuing delay anyway.

You keep pointing at the value of real-life tests. Do note that if you =
run tests with Chromium today, fq_codel may help you: as you know, =
google's congestion control was found to have issues, and there is no =
congestion control coupling happening yet. But we're trying to develop =
something new here, so measuring what's out there right now won't help.


> 2) To make analysis easier from tools like wireshark (my immediate =
need).

Agreed, this is a point in favor of separating. Then again, the =
multiplexing-or-not debate is old and I would guess that such things =
have already been debated? Anyway there are many more pro's and con's to =
this whole thing than what we're discussing here (a lot of it is related =
to middlebox behavior).


> What my gut says and what experiment shows is often very different. I
> can see some problems with splitting tuples like this, like adding an
> extra system call every 10ms or so, and having to explicitly be aware =
of
> joint time stamps from two streams, but I think they are small =
problems
> relative to the potential benefits.
>=20
> 3) To take advantage, where possible, of different scheduling and =
classification
> techniques in the network. A strict drop tail or AQM system won't be
> affected by adding in this support, although I foresee better mixing =
on the
> endpoints as being a benefit across any network technology. I'd like
> to be fiddling with ECN as well.

See above, I don't think that you'd have a benefit, but potentially a =
disadvantage.


>> +1.
>> Separating tuples can help to let the network protect a flow against =
*any*
>> other flow, but for prioritization between flows coming from the same
>> application, you should be much better off with joint congestion =
management,
>> where you have 100% control over priorities and get other benefits =
too. My
>> argument is: "send stuff into the network the right way rather than =
hoping
>> for the network to correct your mistakes."
>=20
> I think it is best to do both.

- discussed above.


> I think it is incorrect to use the word prioritization when it comes
> to the effects of packet scheduling. When I think of prioritization
> I think of using diffserv or dpi to classify packets into bins. When
> I think of scheduling, fair queuing, flow queueing, etc.,
> I think of identifying flows and doing better mixing between them;
> of turning packets back into packets again.

=
http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-12=


"   F34     The browser must support prioritization of
           streams and data."

That's my basis for talking about prioritization. AFAIK, the fact that =
it's listed that way in this document means that it's going to be =
explicitly supported by the JS API.


> So yes, I strongly support good mixing from the application level
> and for it to be as self aware as possible of its total impact on the
> network.
>=20
> But: although web browsers are complex and for many users
> their entire OS (sigh), there is not enough information about
> the hosts's other applications, the network and all the devices
> held there to do all the job, thus giving the network more
> information about flows in general is a good idea.

I disagree because of what I wrote above. When a browser can bundle =
flows together, it means that it can 100% control their impact of these =
flows on each other, and then the network can't do things any better =
than the browser could do by itself.


> And I also strongly encourage experimentation with this stuff.

> Me being me, I designed a bunch of experiments, emulated
> every technology I could (DSL, cable, wifi, ethernet),
> got a lot of data, started looking at captures long before
> I started looking at source code and started raising questions
> here on rmcat. I figure that's backwards from how most
> people operate.

Personally, I would be cautious about drawing conclusions from =
experiments with things that we know to be moving targets. For example, =
I can't see that you would be able to get an answer to the questions =
we're discussing here from experimenting with Chromium today.

Cheers,
Michael


From dave.taht@gmail.com  Sat Jan  4 12:54:48 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D231B1AE094 for ; Sat,  4 Jan 2014 12:54:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.998
X-Spam-Level: *
X-Spam-Status: No, score=1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_STOCK2=3.988, SPF_PASS=-0.001, T_FRT_STOCK2=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0DIePSV2mkM for ; Sat,  4 Jan 2014 12:54:46 -0800 (PST)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 216951AE087 for ; Sat,  4 Jan 2014 12:54:45 -0800 (PST)
Received: by mail-we0-f171.google.com with SMTP id q58so14381539wes.2 for ; Sat, 04 Jan 2014 12:54:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yQxZJNJ93nOmRX3Ub81/4GjzOJd79uakhLNDQSt9wnw=; b=u7eRNZrI387ZsNUfi8NQWVBThpNVw6OvASGK53hck2odkKGGnUwJ6d1lrTJAp9Hyuc BbGdF1Lzif7EBN5VkmQfoMfgmzLon9X9jKI9q+ybrIsCmXFwYh3nhnABDwmEomm2nePP BOAB6/cXV9zjrJqpgOiYe3e5uIgEcV0ZsK7uKsu8MIfNz1rww52kCVHv3L47KkVgURqO CSAFwfto2k6O2CbbLbCqhweK7rxKGmCdezNYMYU3XOd08ycdJOgrcJO4IsE0Q9Yqbq7u 1/Fra/NIwr10Sn06bBuc9hANl+gPBiBqE+j/UjBaVmEzE79msKVG6dxbj5WMq/7z2NHE IttQ==
MIME-Version: 1.0
X-Received: by 10.180.105.199 with SMTP id go7mr6525153wib.53.1388868877909; Sat, 04 Jan 2014 12:54:37 -0800 (PST)
Received: by 10.217.123.69 with HTTP; Sat, 4 Jan 2014 12:54:37 -0800 (PST)
In-Reply-To: <07E05385-225C-4CD9-868C-E86992447BDD@ifi.uio.no>
References:  <52C17E9F.8060703@alvestrand.no>  <52C60213.9000401@alvestrand.no>   <07E05385-225C-4CD9-868C-E86992447BDD@ifi.uio.no>
Date: Sat, 4 Jan 2014 15:54:37 -0500
Message-ID: 
From: Dave Taht 
To: Michael Welzl 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Harald Alvestrand , "rmcat@ietf.org" 
Subject: Re: [rmcat] 5 tuples and rmcat-cc-requirements-01
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 04 Jan 2014 20:54:49 -0000

On Sat, Jan 4, 2014 at 5:28 AM, Michael Welzl  wrote:
> Hi,
>
> You answer both Harald and me in this email; I can't respond to the parts=
 where you address Harald, and so I'll just cut some stuff away below.
>
>
> On 4. jan. 2014, at 05:18, Dave Taht  wrote:
>
>> On Fri, Jan 3, 2014 at 3:25 AM, Michael Welzl  wrote=
:
>>> On 3. jan. 2014, at 01:19, Harald Alvestrand  wro=
te:
>>>
>
> [snip]
>
>
>>> Not so much to me. Dave's gut seems to argue for separate treatment of =
audio
>>> and video in the network - what for? To protect them from each other,
>>> because the sending application doesn't know what it's doing?
>>
>> 0) audio behaves way differently than video, and should be differentiate=
d.
>> I personally care not a whit if my video goes to hell once in a while. I=
 care
>> a lot if my audio does. Videoconferences do contain a lot of visual info=
rmation
>> but audio, despite being truly tiny relatively, is critical.
>
> Tell this to an owner of website that offers WebRTC-supported striptease =
shows  :-)
> My point being: I agree that you describe a common requirement, but this =
decision should really be up to the application designer (via prioritiziati=
on, via the JS API).
>
>
>> 1) To differentiate them from other flows on the network. The sending
>> application
>> can't know what those flows are doing.
>
> I don't think we need this.

I think you are wrong.

> Case 1: consider two RMCAT applications (browsers doing WebRTC) talking t=
o each other across one bottleneck link. If you multiplex flows, irrespecti=
ve of what they are, onto a UDP 5-tuple, you shouldn't need any help from t=
he network: you're in complete control over priorities on the sender side, =
and you have only one bottleneck, i.e. something that acts like a single co=
ngestion controller should give you the best behavior. Remember that we're =
envisioning a delay-based cc. here that minimizes queuing delay anyway. In =
such a setting, I can't see how it would help to use different tuples for a=
udio and video so that e.g. fq_codel could separate them.

Who is we? I'm not envisioning a delay based cc, but only a partially
based one. Delay based cc tcps don't work vs loss based. next
question.

> Case 2: consider the same scenario, but with other flows on the bottlenec=
k that recklessly push up the queue. Then, if you have only one common tupl=
e for video and audio, e.g. sfq is going to give this one tuple one bin, an=
d one queue, and we're back at what I described for case 1 -- separating th=
em would only help to protect the browser's own audio from the browser's ow=
n video by putting them in different bins.
>
> You mentioned that you'd like to do both, help from the network side *and=
* from within the application by coupling the congestion controls. Why, how=
? You might end up with the sender prioritizing flows in one way and the ne=
twork working against that with sfq. I'd say that we should rather try to p=
revent sfq from doing its job on the sub-flows of an rtcweb application.

I think that all on one tuple should be allowed, and on different
tuples allowed also, and let the application designer choose.

>This is not at all to say that fq_codel is a bad thing! It's great if it p=
rotects rtcweb traffic from everything else - but I think that letting it o=
perate on rtcweb sub-flows could give us a behavior that we don't want, for=
 no real gain. The fairness of e.g. sfq may be inappropriate for individual=
 rtcweb flows (it may go against what the person writing the JS app wanted)=
, and the potential delay benefit should pretty much disappear if the commo=
n congestion control is designed to minimize queuing delay anyway.

I don't see how you can get sufficient insight into the underlying TCP
stack to have a common congestion control picture across that and
webrtc.

> You keep pointing at the value of real-life tests. Do note that if you ru=
n tests with Chromium today, fq_codel may help you: as you know, google's c=
ongestion control was found to have issues, and there is no congestion cont=
rol coupling happening yet. But we're trying to develop something new here,=
 so measuring what's out there right now won't help.

What was measured in this series of experiments was chromium vs cubic
tcp, under a variety of dsl, cable, wifi emulations that seem to be
pretty
accurate.

The whole point of the experiment was to get a grip on what happened
today and get insight as to be what could be done tomorrow.


>> 2) To make analysis easier from tools like wireshark (my immediate need)=
.
>
> Agreed, this is a point in favor of separating. Then again, the multiplex=
ing-or-not debate is old and I would guess that such things have already be=
en debated?

I was too busy fixing routers to pay attention. Cites to relevant
arguments in the past on other mailing lists desired.

>Anyway there are many more pro's and con's to this whole thing than what w=
e're discussing here (a lot of it is related to middlebox behavior).

I agree middlebox behavior is a serious problem. I had qualified this
conversation to be talking about two tuples rather than one for voice
and video, and also pointed out the non natted and ipv6 cases as being
the ones I was looking at primarily. I don't see a problem keeping two
ports open rather than one, even with middleboxes, actually, but am
open to opposing arguments.

>
>
>> What my gut says and what experiment shows is often very different. I
>> can see some problems with splitting tuples like this, like adding an
>> extra system call every 10ms or so, and having to explicitly be aware of
>> joint time stamps from two streams, but I think they are small problems
>> relative to the potential benefits.
>>
>> 3) To take advantage, where possible, of different scheduling and classi=
fication
>> techniques in the network. A strict drop tail or AQM system won't be
>> affected by adding in this support, although I foresee better mixing on =
the
>> endpoints as being a benefit across any network technology. I'd like
>> to be fiddling with ECN as well.
>
> See above, I don't think that you'd have a benefit, but potentially a dis=
advantage.

I basically already demonstrated a benefit in the captures I took, and some
additional simulations of isochronous traffic vs variable.

I'll take time out to write a paper after I get more code working. Maybe.

Further experiments are good.

>
>>> +1.
>>> Separating tuples can help to let the network protect a flow against *a=
ny*
>>> other flow, but for prioritization between flows coming from the same
>>> application, you should be much better off with joint congestion manage=
ment,
>>> where you have 100% control over priorities and get other benefits too.=
 My
>>> argument is: "send stuff into the network the right way rather than hop=
ing
>>> for the network to correct your mistakes."
>>
>> I think it is best to do both.
>
> - discussed above.
>
>
>> I think it is incorrect to use the word prioritization when it comes
>> to the effects of packet scheduling. When I think of prioritization
>> I think of using diffserv or dpi to classify packets into bins. When
>> I think of scheduling, fair queuing, flow queueing, etc.,
>> I think of identifying flows and doing better mixing between them;
>> of turning packets back into packets again.
>
> http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-1=
2
>
> "   F34     The browser must support prioritization of
>            streams and data."
>
> That's my basis for talking about prioritization. AFAIK, the fact that it=
's listed that way in this document means that it's going to be explicitly =
supported by the JS API.

Thank you for the steer to the relevant document. I will read.

>
>> So yes, I strongly support good mixing from the application level
>> and for it to be as self aware as possible of its total impact on the
>> network.
>>
>> But: although web browsers are complex and for many users
>> their entire OS (sigh), there is not enough information about
>> the hosts's other applications, the network and all the devices
>> held there to do all the job, thus giving the network more
>> information about flows in general is a good idea.
>
> I disagree because of what I wrote above. When a browser can bundle flows=
 together, it means that it can 100% control their impact of these flows on=
 each other

Agree and there is much fat to be sliced in the codebases I'm looking
at in favor of better mixing.

>, and then the network can't do things any better than the browser could d=
o by itself.

disagree.

>
>
>> And I also strongly encourage experimentation with this stuff.
>
>> Me being me, I designed a bunch of experiments, emulated
>> every technology I could (DSL, cable, wifi, ethernet),
>> got a lot of data, started looking at captures long before
>> I started looking at source code and started raising questions
>> here on rmcat. I figure that's backwards from how most
>> people operate.
>
> Personally, I would be cautious about drawing conclusions from experiment=
s with things that we know to be moving targets. For example, I can't see t=
hat you would be able to get an answer to the questions we're discussing he=
re from experimenting with Chromium today.

I long ago drew a conclusion that current networks have way too much
buffering for any form of congestion control we know of to work right
for videoconferencing vs deployed tcps on cable, wifi, 3g and LTE.
Some hope on DSL & gpon. DSL because most that I have tried already
have some form of aqm or packet scheduling, gpon as it seems pretty
good on uploads, and not horrible on downloads.

As for experimentation, certainly answers can be obtained from the
moving targets!

Chromium is open source, so anybody can hack on it. I got a build done
last night. Adding in the bits of code and packet handling I'm
discussing experimenting with is fairly trivial. (finding where to add
it and working through the overlarge set of c++ abstractions is thus
far proving difficult.)

I am interested in the following experiments:

finding the "right" rate quickly
dealing with non-congestive (e.g. wifi) losses
improving recovery after a congestive loss
better analysis via rtp on separate tuples
looking at the effects of various proposed classification schemes, and
how to detect if they are preserved end to end
what ecn could be used for (and testing for end to end preservation also)
looking at the interactions of what network types exist today
(dsl,cable, wifi, 3g) in general
looking at aqm and packet scheduling vs drop tail behaviors.

Most of the core code we need is already written elsewhere. For
example being able to pay attention to classification, preservation
thereof, and
ECN is handled by these bits of code in mosh. (side note, TOS setting
is wrong for ipv6 in chrome & mosh, you need to use IPPROTO_IPV6 with
IPV6_TCLASS instead of IPPROTO_IP & IP_TOS, easy fix pending)

  /* request explicit congestion notification on received datagrams */
#ifdef HAVE_IP_RECVTOS
  int tosflag =3D true;
  socklen_t tosoptlen =3D sizeof( tosflag );
  if ( setsockopt( _fd, IPPROTO_IP, IP_RECVTOS, &tosflag, tosoptlen ) < 0 )=
 {
    perror( "setsockopt( IP_RECVTOS )" );
  }
#endif
}

string Connection::recv_one( int sock_to_recv, bool nonblocking )
{
  /* receive source address, ECN, and payload in msghdr structure */
  struct sockaddr_in packet_remote_addr;
  struct msghdr header;
  struct iovec msg_iovec;

  char msg_payload[ Session::RECEIVE_MTU ];
  char msg_control[ Session::RECEIVE_MTU ];

  /* receive source address */
  header.msg_name =3D &packet_remote_addr;
  header.msg_namelen =3D sizeof( packet_remote_addr );

  /* receive payload */
  msg_iovec.iov_base =3D msg_payload;
  msg_iovec.iov_len =3D Session::RECEIVE_MTU;
  header.msg_iov =3D &msg_iovec;
  header.msg_iovlen =3D 1;

  /* receive explicit congestion notification */
  header.msg_control =3D msg_control;
  header.msg_controllen =3D Session::RECEIVE_MTU;

  /* receive flags */
  header.msg_flags =3D 0;

  ssize_t received_len =3D recvmsg( sock_to_recv, &header, nonblocking ?
MSG_DONTWAIT : 0 );

  if ( received_len < 0 ) {
    throw NetworkException( "recvmsg", errno );
  }

  if ( header.msg_flags & MSG_TRUNC ) {
    throw NetworkException( "Received oversize datagram", errno );
  }

  /* receive ECN */
  bool congestion_experienced =3D false;

  struct cmsghdr *ecn_hdr =3D CMSG_FIRSTHDR( &header );
  if ( ecn_hdr
       && (ecn_hdr->cmsg_level =3D=3D IPPROTO_IP)
       && (ecn_hdr->cmsg_type =3D=3D IP_TOS) ) {
    /* got one */
    uint8_t *ecn_octet_p =3D (uint8_t *)CMSG_DATA( ecn_hdr );
    assert( ecn_octet_p );

    if ( (*ecn_octet_p & 0x03) =3D=3D 0x03 ) {
      congestion_experienced =3D true;
    }
  }


--=20
Dave T=E4ht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.=
html

>
> Cheers,
> Michael
>



--=20
Dave T=E4ht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.=
html

From john@jlc.net  Sat Jan  4 14:23:34 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34111AE0B2 for ; Sat,  4 Jan 2014 14:23:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.738
X-Spam-Level: 
X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGJRP3WrPnHj for ; Sat,  4 Jan 2014 14:23:32 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 78C621AE0A7 for ; Sat,  4 Jan 2014 14:23:32 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 0B436C94C2; Sat,  4 Jan 2014 17:23:22 -0500 (EST)
Date: Sat, 4 Jan 2014 17:23:22 -0500
From: John Leslie 
To: Dave Taht 
Message-ID: <20140104222321.GA111@verdi>
References:  <52C17E9F.8060703@alvestrand.no>  <52C60213.9000401@alvestrand.no>   <07E05385-225C-4CD9-868C-E86992447BDD@ifi.uio.no> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.1i
Cc: "rmcat@ietf.org" , Michael Welzl 
Subject: Re: [rmcat] 5 tuples and rmcat-cc-requirements-01
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 04 Jan 2014 22:23:34 -0000

Dave Taht  wrote:
>...
> I think that all on one tuple should be allowed, and on different
> tuples allowed also, and let the application designer choose.

--
John Leslie 

From michawe@ifi.uio.no  Mon Jan  6 02:37:40 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1A71ADEB7 for ; Mon,  6 Jan 2014 02:37:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level: 
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AI4dnYy2DVj2 for ; Mon,  6 Jan 2014 02:37:38 -0800 (PST)
Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8B31ADF12 for ; Mon,  6 Jan 2014 02:37:37 -0800 (PST)
Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1W07Yl-0004fr-HH; Mon, 06 Jan 2014 11:37:27 +0100
Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1W07Yl-0001tx-5f; Mon, 06 Jan 2014 11:37:27 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Michael Welzl 
In-Reply-To: <20140104222321.GA111@verdi>
Date: Mon, 6 Jan 2014 11:37:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <47558FF3-BF76-46F2-8AD9-CF312071FF18@ifi.uio.no>
References:  <52C17E9F.8060703@alvestrand.no>  <52C60213.9000401@alvestrand.no>   <07E05385-225C-4CD9-868C-E86992447BDD@ifi.uio.no>  <20140104222321.GA111@verdi>
To: John Leslie 
X-Mailer: Apple Mail (2.1283)
X-UiO-SPF-Received: 
X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 3 sum rcpts/h 5 sum msgs/h 3 total rcpts 11252 max rcpts/h 44 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.05, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: DCD9A004CD07A3980084AAB0F9374F8F7EA2AF09
X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 4010 max/h 16 blacklist 0 greylist 0 ratelimit 0
Cc: "rmcat@ietf.org" , Dave Taht 
Subject: Re: [rmcat] 5 tuples and rmcat-cc-requirements-01
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jan 2014 10:37:40 -0000

+1.

I'll answer the longer email in more detail anyway because of questions =
asked and issues raised, but indeed I think this is the solution that we =
can all live with.

Cheers,
Michael


On 4. jan. 2014, at 23:23, John Leslie wrote:

> Dave Taht  wrote:
>> ...
>> I think that all on one tuple should be allowed, and on different
>> tuples allowed also, and let the application designer choose.
>=20
> --
> John Leslie 


From michawe@ifi.uio.no  Mon Jan  6 03:09:55 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09C11ADFFF for ; Mon,  6 Jan 2014 03:09:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level: 
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcBejfeVrXcb for ; Mon,  6 Jan 2014 03:09:52 -0800 (PST)
Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id C59441ADF8B for ; Mon,  6 Jan 2014 03:09:51 -0800 (PST)
Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1W083y-0006BM-3V; Mon, 06 Jan 2014 12:09:42 +0100
Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1W083x-0001aW-95; Mon, 06 Jan 2014 12:09:42 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=iso-8859-1
From: Michael Welzl 
In-Reply-To: 
Date: Mon, 6 Jan 2014 12:09:40 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <52C17E9F.8060703@alvestrand.no>  <52C60213.9000401@alvestrand.no>   <07E05385-225C-4CD9-868C-E86992447BDD@ifi.uio.no> 
To: Dave Taht 
X-Mailer: Apple Mail (2.1283)
X-UiO-SPF-Received: 
X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 5 sum msgs/h 2 total rcpts 11255 max rcpts/h 44 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.05, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: BB1A70231063538C87D1B2FC4B017A8B3CAD90E0
X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 4011 max/h 16 blacklist 0 greylist 0 ratelimit 0
Cc: Harald Alvestrand , "rmcat@ietf.org" 
Subject: Re: [rmcat] 5 tuples and rmcat-cc-requirements-01
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jan 2014 11:09:55 -0000

>> Case 1: consider two RMCAT applications (browsers doing WebRTC) =
talking to each other across one bottleneck link. If you multiplex =
flows, irrespective of what they are, onto a UDP 5-tuple, you shouldn't =
need any help from the network: you're in complete control over =
priorities on the sender side, and you have only one bottleneck, i.e. =
something that acts like a single congestion controller should give you =
the best behavior. Remember that we're envisioning a delay-based cc. =
here that minimizes queuing delay anyway. In such a setting, I can't see =
how it would help to use different tuples for audio and video so that =
e.g. fq_codel could separate them.
>=20
> Who is we? I'm not envisioning a delay based cc, but only a partially
> based one.

With "we", I meant rmcat, based on its charter. However, my phrasing was =
imprecise: the requirement for RMCAT's congestion control as stated in =
the charter only reads "Low delay and low jitter for the case where =
there is no competing traffic using other algorithms".

I think it's pretty obvious that such an algorithm would incorporate =
some delay measure in its decision (as all 3 current proposals do), and =
- as you also say - only partially base decisions on delay, i.e. not =
ignore other signals such as loss (as all 3 current proposals do). Thus =
I made this assumption about the algorithm that "we" envision.


> Delay based cc tcps don't work vs loss based. next
> question.

Mechanisms can work reasonably well in the presence of TCP, yet minimize =
delay in its absence. All 3 current proposals try to do that in some =
way, and there are several more examples out there. Such mechanisms of =
course work best when they don't even have to compete against TCP =
because e.g. fq_codel gives them their own bin. So that's all fine!

Anyway, the requirement for RMCAT's congestion control is to "low delay =
and jitter", and that's my whole point - the congestion controller =
should produce low delay, and saying that it won't or it can't means =
that you question the RMCAT charter. If that's not your intention, let's =
work from the assumption of a low-delay-producing congestion controller.


>> This is not at all to say that fq_codel is a bad thing! It's great if =
it protects rtcweb traffic from everything else - but I think that =
letting it operate on rtcweb sub-flows could give us a behavior that we =
don't want, for no real gain. The fairness of e.g. sfq may be =
inappropriate for individual rtcweb flows (it may go against what the =
person writing the JS app wanted), and the potential delay benefit =
should pretty much disappear if the common congestion control is =
designed to minimize queuing delay anyway.
>=20
> I don't see how you can get sufficient insight into the underlying TCP
> stack to have a common congestion control picture across that and
> webrtc.

I don't understand why I need to know anything beyond webrtc if all of =
webrtc's traffic is on one tuple and gets its own bin.


>>> 2) To make analysis easier from tools like wireshark (my immediate =
need).
>>=20
>> Agreed, this is a point in favor of separating. Then again, the =
multiplexing-or-not debate is old and I would guess that such things =
have already been debated?
>=20
> I was too busy fixing routers to pay attention. Cites to relevant
> arguments in the past on other mailing lists desired.

I also only know that it was debated, and I guess it can be found in the =
rtcweb list archives. Finding it there is only going to take 2-3 days or =
so  :-)   that list has been extremely noisy.


>>> What my gut says and what experiment shows is often very different. =
I
>>> can see some problems with splitting tuples like this, like adding =
an
>>> extra system call every 10ms or so, and having to explicitly be =
aware of
>>> joint time stamps from two streams, but I think they are small =
problems
>>> relative to the potential benefits.
>>>=20
>>> 3) To take advantage, where possible, of different scheduling and =
classification
>>> techniques in the network. A strict drop tail or AQM system won't be
>>> affected by adding in this support, although I foresee better mixing =
on the
>>> endpoints as being a benefit across any network technology. I'd like
>>> to be fiddling with ECN as well.
>>=20
>> See above, I don't think that you'd have a benefit, but potentially a =
disadvantage.
>=20
> I basically already demonstrated a benefit in the captures I took, and =
some
> additional simulations of isochronous traffic vs variable.

My argument in our discussion (#1) is that coupled congestion control =
would eliminate the need for the network to help rtcweb's individual =
flows to get low delay (and in probably do a better job), and therefore =
it's probably best to multiplex all of rtcweb's traffic on one 5-tuple =
for the sake of delay.

Your argument (#2) is the opposite - separate tuples can be better =
supported by the network, which will give rtcweb's flows lower delay.

In that context, how can you demonstrate a benefit of #2 over #1 when #1 =
isn't even implemented yet?


>> Personally, I would be cautious about drawing conclusions from =
experiments with things that we know to be moving targets. For example, =
I can't see that you would be able to get an answer to the questions =
we're discussing here from experimenting with Chromium today.
>=20
> I long ago drew a conclusion that current networks have way too much
> buffering for any form of congestion control we know of to work right
> for videoconferencing vs deployed tcps on cable, wifi, 3g and LTE.

That's nice but really not what we're discussing here.


> As for experimentation, certainly answers can be obtained from the
> moving targets!
>=20
> Chromium is open source, so anybody can hack on it. I got a build done
> last night.

My point is, AFAIK it does *not* do coupled congestion control, so if =
you measure its behavior you're not measuring what we're talking about. =
Yes we would like to add code on coupled congestion control to it when =
the time comes. We take it step by step.

Cheers,
Michael


From mramalho@cisco.com  Mon Jan  6 06:03:49 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8617F1ADFC9 for ; Mon,  6 Jan 2014 06:03:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.039
X-Spam-Level: 
X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDuw5ZV_6VWV for ; Mon,  6 Jan 2014 06:03:44 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 326681ADFC5 for ; Mon,  6 Jan 2014 06:03:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7908; q=dns/txt; s=iport; t=1389017016; x=1390226616; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pAQkK6M6ionGUgTyAwPmFd4CgiblIO0zu5IdvFUANUU=; b=bnArGGtt61KJ8Gbg9qA0t7VVfAiCBjWi3ybmIW3bsF/yXiQToD/rch8o CEZ0d8Ybmm/Q2ayCeg4re2UXiD0Ghtu573JiMmteD4KTQ88/6lvfT59Hp jWagC23qU/5Qab0EH3xtcfnlgeE23dFJEM/QHq4ASZoK8lWmh4KFJiR32 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAOy2ylKtJV2Z/2dsb2JhbABYgwuBDblHgQoWdIIlAQEBAwE6MgIIAwUHBAIBCA4DBAEBCxQJBzIUCQgCBAENBQiHdAjDKheOLDIxBwaDHoETAQOqLIMtgio
X-IronPort-AV: E=Sophos;i="4.95,613,1384300800"; d="scan'208";a="10797768"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP; 06 Jan 2014 14:03:34 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s06E3YWP016643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Jan 2014 14:03:34 GMT
Received: from xmb-rcd-x12.cisco.com ([169.254.2.37]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Mon, 6 Jan 2014 08:03:34 -0600
From: "Michael Ramalho (mramalho)" 
To: Michael Welzl , Dave Taht 
Thread-Topic: [rmcat] 5 tuples and rmcat-cc-requirements-01
Thread-Index: AQHPBPJn2Omc2tBnIE2iSZr41XouHZptLDmAgAEUHICABE1MgIAAh7SAgAFNRQCAAGeBgIAArvCAgAKBOwD//8kAUA==
Date: Mon, 6 Jan 2014 14:03:33 +0000
Message-ID: 
References:  <52C17E9F.8060703@alvestrand.no>  <52C60213.9000401@alvestrand.no>   <07E05385-225C-4CD9-868C-E86992447BDD@ifi.uio.no>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.69.148]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Harald Alvestrand , "rmcat@ietf.org" 
Subject: Re: [rmcat] 5 tuples and rmcat-cc-requirements-01
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jan 2014 14:03:49 -0000

Michael/Dave,

I am trying to save this thread, as you both have important points.

However, when Michael talks about coupled congestion control he almost excl=
usively talks about coupling of the congestion control of flows ON ONE HOST=
. With that perspective, the coupling of the congestion control of the indi=
vidual flows ON ONE HOST makes sense (even if they are undifferentiated on =
the sent 5-tuple).

And when Dave talks about coupled congestion control, he argues for de-coup=
ling of the 5-tuples because he knows that coupling the flows ACROSS MULTIP=
LE HOSTS isn't possible on the time scales required (tens of milliseconds) =
and the best that can be done is some network-based decoupling of the indiv=
idual voice and video flows. And Dave thinks that any cross-flow coupling i=
s near hopeless whenever a "long-enough-lived" TCPs crank up (and I agree -=
 and hope I paraphrased his position correctly).

In other words, Dave is talking about traffic AGGREGATES from many hosts on=
 a given (usually bottleneck, bufferbloated) link.

I have had this communication issue with Dr. Welzl in the past (me talking =
about traffic aggregates and he talking about congestion control coupling o=
n a given host).

Now ... with this as a background ... don't you both sound correct from you=
r perspectives?

[Off Soapbox, hope this helped.]

Ramalho

-----Original Message-----
From: rmcat [mailto:rmcat-bounces@ietf.org] On Behalf Of Michael Welzl
Sent: Monday, January 06, 2014 6:10 AM
To: Dave Taht
Cc: Harald Alvestrand; rmcat@ietf.org
Subject: Re: [rmcat] 5 tuples and rmcat-cc-requirements-01

>> Case 1: consider two RMCAT applications (browsers doing WebRTC) talking =
to each other across one bottleneck link. If you multiplex flows, irrespect=
ive of what they are, onto a UDP 5-tuple, you shouldn't need any help from =
the network: you're in complete control over priorities on the sender side,=
 and you have only one bottleneck, i.e. something that acts like a single c=
ongestion controller should give you the best behavior. Remember that we're=
 envisioning a delay-based cc. here that minimizes queuing delay anyway. In=
 such a setting, I can't see how it would help to use different tuples for =
audio and video so that e.g. fq_codel could separate them.
>=20
> Who is we? I'm not envisioning a delay based cc, but only a partially=20
> based one.

With "we", I meant rmcat, based on its charter. However, my phrasing was im=
precise: the requirement for RMCAT's congestion control as stated in the ch=
arter only reads "Low delay and low jitter for the case where there is no c=
ompeting traffic using other algorithms".

I think it's pretty obvious that such an algorithm would incorporate some d=
elay measure in its decision (as all 3 current proposals do), and - as you =
also say - only partially base decisions on delay, i.e. not ignore other si=
gnals such as loss (as all 3 current proposals do). Thus I made this assump=
tion about the algorithm that "we" envision.


> Delay based cc tcps don't work vs loss based. next question.

Mechanisms can work reasonably well in the presence of TCP, yet minimize de=
lay in its absence. All 3 current proposals try to do that in some way, and=
 there are several more examples out there. Such mechanisms of course work =
best when they don't even have to compete against TCP because e.g. fq_codel=
 gives them their own bin. So that's all fine!

Anyway, the requirement for RMCAT's congestion control is to "low delay and=
 jitter", and that's my whole point - the congestion controller should prod=
uce low delay, and saying that it won't or it can't means that you question=
 the RMCAT charter. If that's not your intention, let's work from the assum=
ption of a low-delay-producing congestion controller.


>> This is not at all to say that fq_codel is a bad thing! It's great if it=
 protects rtcweb traffic from everything else - but I think that letting it=
 operate on rtcweb sub-flows could give us a behavior that we don't want, f=
or no real gain. The fairness of e.g. sfq may be inappropriate for individu=
al rtcweb flows (it may go against what the person writing the JS app wante=
d), and the potential delay benefit should pretty much disappear if the com=
mon congestion control is designed to minimize queuing delay anyway.
>=20
> I don't see how you can get sufficient insight into the underlying TCP=20
> stack to have a common congestion control picture across that and=20
> webrtc.

I don't understand why I need to know anything beyond webrtc if all of webr=
tc's traffic is on one tuple and gets its own bin.


>>> 2) To make analysis easier from tools like wireshark (my immediate need=
).
>>=20
>> Agreed, this is a point in favor of separating. Then again, the multiple=
xing-or-not debate is old and I would guess that such things have already b=
een debated?
>=20
> I was too busy fixing routers to pay attention. Cites to relevant=20
> arguments in the past on other mailing lists desired.

I also only know that it was debated, and I guess it can be found in the rt=
cweb list archives. Finding it there is only going to take 2-3 days or so  =
:-)   that list has been extremely noisy.


>>> What my gut says and what experiment shows is often very different.=20
>>> I can see some problems with splitting tuples like this, like adding=20
>>> an extra system call every 10ms or so, and having to explicitly be=20
>>> aware of joint time stamps from two streams, but I think they are=20
>>> small problems relative to the potential benefits.
>>>=20
>>> 3) To take advantage, where possible, of different scheduling and=20
>>> classification techniques in the network. A strict drop tail or AQM=20
>>> system won't be affected by adding in this support, although I=20
>>> foresee better mixing on the endpoints as being a benefit across any=20
>>> network technology. I'd like to be fiddling with ECN as well.
>>=20
>> See above, I don't think that you'd have a benefit, but potentially a di=
sadvantage.
>=20
> I basically already demonstrated a benefit in the captures I took, and=20
> some additional simulations of isochronous traffic vs variable.

My argument in our discussion (#1) is that coupled congestion control would=
 eliminate the need for the network to help rtcweb's individual flows to ge=
t low delay (and in probably do a better job), and therefore it's probably =
best to multiplex all of rtcweb's traffic on one 5-tuple for the sake of de=
lay.

Your argument (#2) is the opposite - separate tuples can be better supporte=
d by the network, which will give rtcweb's flows lower delay.

In that context, how can you demonstrate a benefit of #2 over #1 when #1 is=
n't even implemented yet?


>> Personally, I would be cautious about drawing conclusions from experimen=
ts with things that we know to be moving targets. For example, I can't see =
that you would be able to get an answer to the questions we're discussing h=
ere from experimenting with Chromium today.
>=20
> I long ago drew a conclusion that current networks have way too much=20
> buffering for any form of congestion control we know of to work right=20
> for videoconferencing vs deployed tcps on cable, wifi, 3g and LTE.

That's nice but really not what we're discussing here.


> As for experimentation, certainly answers can be obtained from the=20
> moving targets!
>=20
> Chromium is open source, so anybody can hack on it. I got a build done=20
> last night.

My point is, AFAIK it does *not* do coupled congestion control, so if you m=
easure its behavior you're not measuring what we're talking about. Yes we w=
ould like to add code on coupled congestion control to it when the time com=
es. We take it step by step.

Cheers,
Michael


From michawe@ifi.uio.no  Mon Jan  6 07:22:10 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A95D1AE03A for ; Mon,  6 Jan 2014 07:22:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level: 
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZf_hguQ8ok7 for ; Mon,  6 Jan 2014 07:22:08 -0800 (PST)
Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id DA5D91AE037 for ; Mon,  6 Jan 2014 07:22:07 -0800 (PST)
Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1W0C05-0000wH-Iz; Mon, 06 Jan 2014 16:21:57 +0100
Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1W0C05-0007df-4M; Mon, 06 Jan 2014 16:21:57 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Michael Welzl 
In-Reply-To: 
Date: Mon, 6 Jan 2014 16:21:56 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <52C17E9F.8060703@alvestrand.no>  <52C60213.9000401@alvestrand.no>   <07E05385-225C-4CD9-868C-E86992447BDD@ifi.uio.no>   
To: Michael Ramalho (mramalho) 
X-Mailer: Apple Mail (2.1283)
X-UiO-SPF-Received: 
X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 8 sum msgs/h 2 total rcpts 11268 max rcpts/h 44 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.05, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 85A304CA3DD773F9EB689A7B9154A74AD6E58F2B
X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 4016 max/h 16 blacklist 0 greylist 0 ratelimit 0
Cc: Harald Alvestrand , Dave Taht , "rmcat@ietf.org" 
Subject: Re: [rmcat] 5 tuples and rmcat-cc-requirements-01
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jan 2014 15:22:10 -0000

On 6. jan. 2014, at 15:03, Michael Ramalho (mramalho) wrote:

> Michael/Dave,
>=20
> I am trying to save this thread, as you both have important points.
>=20
> However, when Michael talks about coupled congestion control he almost =
exclusively talks about coupling of the congestion control of flows ON =
ONE HOST. With that perspective, the coupling of the congestion control =
of the individual flows ON ONE HOST makes sense (even if they are =
undifferentiated on the sent 5-tuple).

Confirmed.


> And when Dave talks about coupled congestion control, he argues for =
de-coupling of the 5-tuples because he knows that coupling the flows =
ACROSS MULTIPLE HOSTS isn't possible on the time scales required (tens =
of milliseconds) and the best that can be done is some network-based =
decoupling of the individual voice and video flows. And Dave thinks that =
any cross-flow coupling is near hopeless whenever a "long-enough-lived" =
TCPs crank up (and I agree - and hope I paraphrased his position =
correctly).
>=20
> In other words, Dave is talking about traffic AGGREGATES from many =
hosts on a given (usually bottleneck, bufferbloated) link.

Well... frankly I assume that Dave is thinking about fq_codel, and =
fq_codel would give every tuple a bin. So the scenario in my mind is:
1 tuple from 1 host getting a bin in fq_codel
vs.
multiple tuples from 1 host getting a bin each in fq_codel
... and then, whether there are even more tuples from even more hosts or =
not doesn't matter much for our discussion I think.


> I have had this communication issue with Dr. Welzl in the past (me =
talking about traffic aggregates and he talking about congestion control =
coupling on a given host).

Sorry!  :-(


> Now ... with this as a background ... don't you both sound correct =
from your perspectives?
>=20
> [Off Soapbox, hope this helped.]

Dunno, hope I could clarify...

Cheers,
Michael


From ingemar.s.johansson@ericsson.com  Wed Jan  8 00:13:58 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F6B1AD739 for ; Wed,  8 Jan 2014 00:13:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKzFtnnAjAh1 for ; Wed,  8 Jan 2014 00:13:56 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 57E291AE190 for ; Wed,  8 Jan 2014 00:13:55 -0800 (PST)
X-AuditID: c1b4fb38-b7f2c8e000006d25-7e-52cd08b91c0a
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id FC.BC.27941.9B80DC25; Wed,  8 Jan 2014 09:13:45 +0100 (CET)
Received: from ESESSMB205.ericsson.se ([169.254.5.19]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0347.000; Wed, 8 Jan 2014 09:13:08 +0100
From: Ingemar Johansson S 
To: Michael Welzl , Dave Taht 
Thread-Topic: [rmcat] 5 tuples and rmcat-cc-requirements-01
Thread-Index: AQHPCvL9kjbxGh32A02uEFAEW360oJp6d+4w
Date: Wed, 8 Jan 2014 08:13:07 +0000
Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA1C40786C@ESESSMB205.ericsson.se>
References:  <52C17E9F.8060703@alvestrand.no>  <52C60213.9000401@alvestrand.no>   <07E05385-225C-4CD9-868C-E86992447BDD@ifi.uio.no>  
In-Reply-To: 
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.16]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvre5OjrNBBmsPKlrs2XiSxeJYXxeb xY+zO1ktVt/8wObA4nFlwhVWj52z7rJ7LFnyk8lj9eqHzAEsUVw2Kak5mWWpRfp2CVwZ037N YS5YZ1exqW86UwPjBsMuRk4OCQETiXP3pzBB2GISF+6tZ+ti5OIQEjjCKLF5631mkISQwCJG ifv/rEFsNgEbiZWHvjOC2CIC7hJvlxwAq2EWCJRoe7iPFcQWFrCSWHjmJlSNtcSD1j4WCNtI YuPEmWBxFgEViW13v4D18gr4Spz+8Z4FYnE7i8SN4y/BijgF7CRmvLzBBmIzCshK3P9+jwVi mbjErSfzoa4WkFiy5zwzhC0q8fLxP1YIW1Fi59l2qON0JBbs/sQGYWtLLFv4GmqxoMTJmU9Y JjCKzUIydhaSlllIWmYhaVnAyLKKkaM4tTgpN93IYBMjMJ4ObvltsYPx8l+bQ4zSHCxK4rwf 3zoHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUAkbAmV8rctlDP5SWhMa95PgorMnwjz8kefmE BWU7nvdtcPo6JfLApNdXVmrs/532f/4/2UfPOVfNeHvx662Ti7+umLZt5znT0LJv1854fNp1 rmWNtAZn9Y85ASfeHLcVu6Y16atCoIz2yrL44Bdxfq9npL1t/bv/pdTHaK57Jx5odHfcL7tX fOyBoRJLcUaioRZzUXEiAMBZAdN1AgAA
Cc: Harald Alvestrand , "rmcat@ietf.org" 
Subject: Re: [rmcat] 5 tuples and rmcat-cc-requirements-01
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Jan 2014 08:13:58 -0000

Hi

Have not followed the whole thread due to an abundance of XMAS but anyway a=
 few comments.=20
I agree that fq_codel and similar is very good as it can help to maintain v=
ery low latency and packet loss for small flows, the challenge is however d=
eployment. Same goes with ECN, it helps to do away with packet drops as con=
gestion signal but adoption of ECN is very slow. Perhaps the emerging work =
around Immediate ECN can increase the interest but it is anyway a long way =
to go..

Both more advanced AQMs and ECN suffer from the deplyment problem and for t=
hat reason it is necessary to use RMCAT congestion controls that are a hybr=
id of delay and loss/ECN based and the congestion control is then likely to=
 need to rely on delay measurements for a foreseable future.

Delay based CC algos are not bullet proof though, it is easy for a loss bas=
ed TCP to starve out an application that use delay based CC. One can of cou=
rse borrow ideas such as Hamilton Delay TCP but it is not completely withou=
t complications.

In the best of worlds I would see something like Immediate ECN or at least =
wide AQM deployment but until that becomes reality I guess we will have to =
stick to delay based CC and make that work as good as possible.

/Ingemar

> -----Original Message-----
> From: Michael Welzl [mailto:michawe@ifi.uio.no]
> Sent: den 6 januari 2014 12:10
> To: Dave Taht
> Cc: Harald Alvestrand; rmcat@ietf.org
> Subject: Re: [rmcat] 5 tuples and rmcat-cc-requirements-01
>=20
> >> Case 1: consider two RMCAT applications (browsers doing WebRTC)
> talking to each other across one bottleneck link. If you multiplex flows,
> irrespective of what they are, onto a UDP 5-tuple, you shouldn't need any
> help from the network: you're in complete control over priorities on the
> sender side, and you have only one bottleneck, i.e. something that acts l=
ike a
> single congestion controller should give you the best behavior. Remember
> that we're envisioning a delay-based cc. here that minimizes queuing dela=
y
> anyway. In such a setting, I can't see how it would help to use different
> tuples for audio and video so that e.g. fq_codel could separate them.
> >
> > Who is we? I'm not envisioning a delay based cc, but only a partially
> > based one.
>=20
> With "we", I meant rmcat, based on its charter. However, my phrasing was
> imprecise: the requirement for RMCAT's congestion control as stated in th=
e
> charter only reads "Low delay and low jitter for the case where there is =
no
> competing traffic using other algorithms".
>=20
> I think it's pretty obvious that such an algorithm would incorporate some
> delay measure in its decision (as all 3 current proposals do), and - as y=
ou also
> say - only partially base decisions on delay, i.e. not ignore other signa=
ls such
> as loss (as all 3 current proposals do). Thus I made this assumption abou=
t the
> algorithm that "we" envision.
>=20
>=20
> > Delay based cc tcps don't work vs loss based. next question.
>=20
> Mechanisms can work reasonably well in the presence of TCP, yet minimize
> delay in its absence. All 3 current proposals try to do that in some way,=
 and
> there are several more examples out there. Such mechanisms of course
> work best when they don't even have to compete against TCP because e.g.
> fq_codel gives them their own bin. So that's all fine!
>=20
> Anyway, the requirement for RMCAT's congestion control is to "low delay
> and jitter", and that's my whole point - the congestion controller should
> produce low delay, and saying that it won't or it can't means that you
> question the RMCAT charter. If that's not your intention, let's work from=
 the
> assumption of a low-delay-producing congestion controller.
>=20
>=20
> >> This is not at all to say that fq_codel is a bad thing! It's great if =
it protects
> rtcweb traffic from everything else - but I think that letting it operate=
 on
> rtcweb sub-flows could give us a behavior that we don't want, for no real
> gain. The fairness of e.g. sfq may be inappropriate for individual rtcweb=
 flows
> (it may go against what the person writing the JS app wanted), and the
> potential delay benefit should pretty much disappear if the common
> congestion control is designed to minimize queuing delay anyway.
> >
> > I don't see how you can get sufficient insight into the underlying TCP
> > stack to have a common congestion control picture across that and
> > webrtc.
>=20
> I don't understand why I need to know anything beyond webrtc if all of
> webrtc's traffic is on one tuple and gets its own bin.
>=20
>=20
> >>> 2) To make analysis easier from tools like wireshark (my immediate
> need).
> >>
> >> Agreed, this is a point in favor of separating. Then again, the multip=
lexing-
> or-not debate is old and I would guess that such things have already been
> debated?
> >
> > I was too busy fixing routers to pay attention. Cites to relevant
> > arguments in the past on other mailing lists desired.
>=20
> I also only know that it was debated, and I guess it can be found in the
> rtcweb list archives. Finding it there is only going to take 2-3 days or =
so  :-)
> that list has been extremely noisy.
>=20
>=20
> >>> What my gut says and what experiment shows is often very different.
> >>> I can see some problems with splitting tuples like this, like adding
> >>> an extra system call every 10ms or so, and having to explicitly be
> >>> aware of joint time stamps from two streams, but I think they are
> >>> small problems relative to the potential benefits.
> >>>
> >>> 3) To take advantage, where possible, of different scheduling and
> >>> classification techniques in the network. A strict drop tail or AQM
> >>> system won't be affected by adding in this support, although I
> >>> foresee better mixing on the endpoints as being a benefit across any
> >>> network technology. I'd like to be fiddling with ECN as well.
> >>
> >> See above, I don't think that you'd have a benefit, but potentially a
> disadvantage.
> >
> > I basically already demonstrated a benefit in the captures I took, and
> > some additional simulations of isochronous traffic vs variable.
>=20
> My argument in our discussion (#1) is that coupled congestion control wou=
ld
> eliminate the need for the network to help rtcweb's individual flows to g=
et
> low delay (and in probably do a better job), and therefore it's probably =
best
> to multiplex all of rtcweb's traffic on one 5-tuple for the sake of delay=
.
>=20
> Your argument (#2) is the opposite - separate tuples can be better suppor=
ted
> by the network, which will give rtcweb's flows lower delay.
>=20
> In that context, how can you demonstrate a benefit of #2 over #1 when #1
> isn't even implemented yet?
>=20
>=20
> >> Personally, I would be cautious about drawing conclusions from
> experiments with things that we know to be moving targets. For example, I
> can't see that you would be able to get an answer to the questions we're
> discussing here from experimenting with Chromium today.
> >
> > I long ago drew a conclusion that current networks have way too much
> > buffering for any form of congestion control we know of to work right
> > for videoconferencing vs deployed tcps on cable, wifi, 3g and LTE.
>=20
> That's nice but really not what we're discussing here.
>=20
>=20
> > As for experimentation, certainly answers can be obtained from the
> > moving targets!
> >
> > Chromium is open source, so anybody can hack on it. I got a build done
> > last night.
>=20
> My point is, AFAIK it does *not* do coupled congestion control, so if you
> measure its behavior you're not measuring what we're talking about. Yes w=
e
> would like to add code on coupled congestion control to it when the time
> comes. We take it step by step.
>=20
> Cheers,
> Michael
>=20


From john@jlc.net  Wed Jan  8 04:40:31 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1040F1AE36F for ; Wed,  8 Jan 2014 04:40:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.738
X-Spam-Level: 
X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-RDF_16X6rU for ; Wed,  8 Jan 2014 04:40:29 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 8E41B1AE36A for ; Wed,  8 Jan 2014 04:40:29 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 168ADC94BF; Wed,  8 Jan 2014 07:40:19 -0500 (EST)
Date: Wed, 8 Jan 2014 07:40:19 -0500
From: John Leslie 
To: Ingemar Johansson S 
Message-ID: <20140108124019.GB18453@verdi>
References:  <52C17E9F.8060703@alvestrand.no>  <52C60213.9000401@alvestrand.no>   <07E05385-225C-4CD9-868C-E86992447BDD@ifi.uio.no>   <81564C0D7D4D2A4B9A86C8C7404A13DA1C40786C@ESESSMB205.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA1C40786C@ESESSMB205.ericsson.se>
User-Agent: Mutt/1.4.1i
Cc: Harald Alvestrand , Dave Taht , Michael Welzl , "rmcat@ietf.org" 
Subject: Re: [rmcat] 5 tuples and rmcat-cc-requirements-01
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Jan 2014 12:40:31 -0000

Ingemar Johansson S  wrote:
> 
> I agree that fq_codel and similar is very good as it can help to
> maintain very low latency and packet loss for small flows, the
> challenge is however deployment.

   I suggest working on diagnostic tools then -- to determine where
fq_codel/similar is or is not deployed at a bottleneck.

> Same goes with ECN, it helps to do away with packet drops as
> congestion signal but adoption of ECN is very slow. Perhaps the
> emerging work around Immediate ECN can increase the interest but
> it is anyway a long way to go..

   Again, work on diagnostic tools would help -- to determine where
Immediate ECN is or is not deployed.

   And BTW, writing a definition of Immediate ECN would help...

--
John Leslie 

From lars@netapp.com  Thu Jan 16 00:37:01 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B731B1AE04C for ; Thu, 16 Jan 2014 00:37:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.44
X-Spam-Level: 
X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0Vl0DZx9pyU for ; Thu, 16 Jan 2014 00:36:59 -0800 (PST)
Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id D9A741ADEA7 for ; Thu, 16 Jan 2014 00:36:59 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.95,666,1384329600";  d="asc'?scan'208";a="96341011"
Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx11-out.netapp.com with ESMTP; 16 Jan 2014 00:36:48 -0800
Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Thu, 16 Jan 2014 00:36:48 -0800
From: "Eggert, Lars" 
To: rmcat WG 
Thread-Topic: WG adoption of draft-singh-rmcat-cc-eval?
Thread-Index: AQHPEpYXwCGFx0stw0qE8XczVDv3zA==
Date: Thu, 16 Jan 2014 08:36:47 +0000
Message-ID: <7E50030C-4E5B-4185-9AA8-6AEE50BE1476@netapp.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.106.53.51]
Content-Type: multipart/signed; boundary="Apple-Mail=_8933744C-80BB-41CF-A7EE-12210F20C94A"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Subject: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jan 2014 08:37:01 -0000

--Apple-Mail=_8933744C-80BB-41CF-A7EE-12210F20C94A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

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

--Apple-Mail=_8933744C-80BB-41CF-A7EE-12210F20C94A
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQCVAwUBUteaIdZcnpRveo1xAQJKTQP/Z8dAmUzWs9xp42frCRe3QRbO8OlFPxsH
/fMwIqf9Pn9l9rV3MOrzB0MQMe838tTIjp8SI5DtwrPOUo5m+u1dYHdWTnJFUDSK
E846McR+T1BdN1jeKoajpfVNYueAHn8XAQv7rHhW2t6Y7mw1/B2sO9t1wdmWwXU0
ylfclptgKH0=
=l7rJ
-----END PGP SIGNATURE-----

--Apple-Mail=_8933744C-80BB-41CF-A7EE-12210F20C94A--

From michawe@ifi.uio.no  Thu Jan 16 06:31:46 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8D31AE349 for ; Thu, 16 Jan 2014 06:31:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLpV5hRx3357 for ; Thu, 16 Jan 2014 06:31:43 -0800 (PST)
Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4331AE36F for ; Thu, 16 Jan 2014 06:31:43 -0800 (PST)
Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1W3nyk-0005Wf-8u; Thu, 16 Jan 2014 15:31:30 +0100
Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1W3nyj-0007XE-QF; Thu, 16 Jan 2014 15:31:30 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_AD38A944-F102-407B-80AF-93FF18F65695"
From: Michael Welzl 
In-Reply-To: <7E50030C-4E5B-4185-9AA8-6AEE50BE1476@netapp.com>
Date: Thu, 16 Jan 2014 15:31:26 +0100
Message-Id: <6BF44A6D-215B-4F02-9E9A-74B00BC4DADE@ifi.uio.no>
References: <7E50030C-4E5B-4185-9AA8-6AEE50BE1476@netapp.com>
To: "Eggert, Lars" 
X-Mailer: Apple Mail (2.1283)
X-UiO-SPF-Received: 
X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 4 sum rcpts/h 15 sum msgs/h 7 total rcpts 11663 max rcpts/h 44 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.086, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: F599805D6B418389A4EAD931EBECAC56313F8985
X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 4180 max/h 16 blacklist 0 greylist 0 ratelimit 0
Cc: rmcat WG 
Subject: Re: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jan 2014 14:31:46 -0000

--Apple-Mail=_AD38A944-F102-407B-80AF-93FF18F65695
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

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


On 16. jan. 2014, at 09:36, Eggert, Lars wrote:

> Hi,
>=20
> 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.
>=20
> 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.
>=20
> 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...)
>=20
> Lars


--Apple-Mail=_AD38A944-F102-407B-80AF-93FF18F65695
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

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


On 16. jan. 2014, at 09:36, Eggert, Lars =
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

=

--Apple-Mail=_AD38A944-F102-407B-80AF-93FF18F65695--

From mramalho@cisco.com  Thu Jan 16 07:58:08 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0805F1AE35F for ; Thu, 16 Jan 2014 07:58:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.038
X-Spam-Level: 
X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-X04RBN_B8G for ; Thu, 16 Jan 2014 07:58:06 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id C48F61AE0E2 for ; Thu, 16 Jan 2014 07:58:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11028; q=dns/txt; s=iport; t=1389887874; x=1391097474; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8cos52fbc8+/9nK9vhDwYp5YxhBa+U5AxU3yq/fXJbY=; b=MUA2pYzmiAdHztUBgheMw3G3vEYN9R2w/ZVHV6qMZ0SBcapZEwLa1PWY RHYKpgBhb4S+mWLpL2zf/B99tJP9OXIlUh69V29CARPQRAsMnkqaNR7w3 InxCsOOW9Pq5wWTyPkIQN/B73zxhPnkP7DigL+PsIkwWAFPuQcD1rCVcD g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlEFAJIA2FKtJV2b/2dsb2JhbABZgkdEOFa7C4EMFnSCJQEBAQICLT8KAxACAQgOAwQBAQsdBzIUCQgCBA4FCAGHew3ESReOHRACAR4xBgGDJIEUBJlSkGaDLYIq
X-IronPort-AV: E=Sophos;i="4.95,668,1384300800"; d="scan'208,217";a="13346352"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP; 16 Jan 2014 15:57:52 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0GFvq1d030642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Jan 2014 15:57:52 GMT
Received: from xmb-rcd-x12.cisco.com ([169.254.2.37]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Thu, 16 Jan 2014 09:57:52 -0600
From: "Michael Ramalho (mramalho)" 
To: Michael Welzl , "Eggert, Lars" 
Thread-Topic: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
Thread-Index: AQHPEpYXwCGFx0stw0qE8XczVDv3zJqHzq8A//+uh4A=
Date: Thu, 16 Jan 2014 15:57:51 +0000
Message-ID: 
References: <7E50030C-4E5B-4185-9AA8-6AEE50BE1476@netapp.com> <6BF44A6D-215B-4F02-9E9A-74B00BC4DADE@ifi.uio.no>
In-Reply-To: <6BF44A6D-215B-4F02-9E9A-74B00BC4DADE@ifi.uio.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.131.12.90]
Content-Type: multipart/alternative; boundary="_000_D21571530BF9644D9A443D6BD95B910322FFF5D6xmbrcdx12ciscoc_"
MIME-Version: 1.0
Cc: rmcat WG 
Subject: Re: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jan 2014 15:58:08 -0000

--_000_D21571530BF9644D9A443D6BD95B910322FFF5D6xmbrcdx12ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Michael,

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

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

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

Assuming that our work will eventually have a delay-sensing component, we w=
ill certainly have visibility into the RTT and estimated one way delays (OW=
D). 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 h=
ave to propagate that oversight into our work.

Best,

Michael Ramalho,Ph.D.

From: rmcat [mailto:rmcat-bounces@ietf.org] 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.

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

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

Cheers,
Michael


On 16. jan. 2014, at 09:36, Eggert, Lars 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, the=
re consensus was that the WG wanted to wait a bit longer to see how the doc=
ument 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 do=
ing a good job in editing the draft and reflecting the discussions we've be=
en having.

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

Lars


--_000_D21571530BF9644D9A443D6BD95B910322FFF5D6xmbrcdx12ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Michael,


 <=
/p>

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


 <=
/p>

“Most congestion co=
ntrols are RTT-dependent, so I guess this is something we'll just have to l=
ive with.”


 <=
/p>

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


 <=
/p>

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


 <=
/p>

Just because old TCPs dyn=
amics were sensitive to RTT doesn’t mean that we have to propagate th=
at oversight into our work.


 <=
/p>

Best,

 <=
/p>

Michael Ramalho,Ph.D.


 <=
/p>





From: rmcat [m=
ailto:rmcat-bounces@ietf.org]
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?<=
/o:p>






 


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 r=
esponses: http://www.ietf.org/mail-archive/web/rmcat/current/msg0068=
0.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 think=
s about it.






 






Cheers,






Michael






 






 










On 16. jan. 2014, at 09:36, Eggert, Lars 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, the=
re consensus was that the WG wanted to wait a bit longer to see how the doc=
ument 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 do=
ing a good job in editing the draft and reflecting the discussions we've be=
en having.



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



Lars






 








--_000_D21571530BF9644D9A443D6BD95B910322FFF5D6xmbrcdx12ciscoc_--

From lars@netapp.com  Thu Jan 16 08:30:55 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3733D1AE0DA for ; Thu, 16 Jan 2014 08:30:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.44
X-Spam-Level: 
X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_3LRbzc68DY for ; Thu, 16 Jan 2014 08:30:53 -0800 (PST)
Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 693221AE0A0 for ; Thu, 16 Jan 2014 08:30:53 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.95,668,1384329600";  d="asc'?scan'208";a="96417467"
Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx11-out.netapp.com with ESMTP; 16 Jan 2014 08:30:41 -0800
Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Thu, 16 Jan 2014 08:30:41 -0800
From: "Eggert, Lars" 
To: "Michael Ramalho (mramalho)" 
Thread-Topic: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
Thread-Index: AQHPEpYXwCGFx0stw0qE8XczVDv3zJqH8DYAgAAYJYCAAAkqgA==
Date: Thu, 16 Jan 2014 16:30:40 +0000
Message-ID: <88F31901-307B-4BDC-9551-9CBEFBB77F52@netapp.com>
References: <7E50030C-4E5B-4185-9AA8-6AEE50BE1476@netapp.com> <6BF44A6D-215B-4F02-9E9A-74B00BC4DADE@ifi.uio.no> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.106.53.51]
Content-Type: multipart/signed; boundary="Apple-Mail=_9F7ED029-CD94-44D4-A93D-21F2F9705ACA"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Cc: rmcat WG , Michael Welzl 
Subject: Re: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jan 2014 16:30:55 -0000

--Apple-Mail=_9F7ED029-CD94-44D4-A93D-21F2F9705ACA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

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)  =
wrote:

> Michael,
> =20
> While not a commentary on your entire thread, I do have a nit with the =
following sentence in your post:
> =20
> =93Most congestion controls are RTT-dependent, so I guess this is =
something we'll just have to live with.=94
> =20
> 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 =96 =
effectively normalizing out the RTT for the purposes of making the rate =
of increase/decrease appropriate for the RTT it sees.
> =20
> 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 =93the RMCAT =
algorithm=94 WOULD have a control loop rate adjustment that is dependent =
on OWD or RTT.
> =20
> Just because old TCPs dynamics were sensitive to RTT doesn=92t mean =
that we have to propagate that oversight into our work.
> =20
> Best,
> =20
> Michael Ramalho,Ph.D.
> =20
> From: rmcat [mailto:rmcat-bounces@ietf.org] 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?
> =20
> I vote for adoption.
> =20
> 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
> =20
> 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.
> =20
> Cheers,
> Michael
> =20
> =20
> On 16. jan. 2014, at 09:36, Eggert, Lars wrote:
>=20
>=20
> Hi,
>=20
> 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.
>=20
> 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.
>=20
> 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...)
>=20
> Lars


--Apple-Mail=_9F7ED029-CD94-44D4-A93D-21F2F9705ACA
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQCVAwUBUtgJL9ZcnpRveo1xAQJM+QQAn7aAIFsc7B6/H8MJ57nALBcUDvK6uB0Q
dTeLL8c/8FN1hUroMgM8wgFyoiCCQCFkqFTfQTWtSWofFBSPgOxQeDlxIkyb4tw4
2C8jiSdbvT/MOrRmluvHXvFBTSKXF00MlGuokJYjRp0EfLhSFBRzsrte4eNtERUJ
U2xl+Qig/1Q=
=vvH8
-----END PGP SIGNATURE-----

--Apple-Mail=_9F7ED029-CD94-44D4-A93D-21F2F9705ACA--

From michawe@ifi.uio.no  Fri Jan 17 00:01:00 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C7A1ADFAA for ; Fri, 17 Jan 2014 00:01:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvH3cMbHJeyb for ; Fri, 17 Jan 2014 00:00:58 -0800 (PST)
Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 937751ADDDA for ; Fri, 17 Jan 2014 00:00:57 -0800 (PST)
Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1W44M8-0004B9-7M; Fri, 17 Jan 2014 09:00:44 +0100
Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1W44M7-0006YJ-Km; Fri, 17 Jan 2014 09:00:44 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_C94C69A7-0657-4B48-858E-B17C42AA4B6D"
From: Michael Welzl 
In-Reply-To: 
Date: Fri, 17 Jan 2014 09:00:42 +0100
Message-Id: 
References: <7E50030C-4E5B-4185-9AA8-6AEE50BE1476@netapp.com> <6BF44A6D-215B-4F02-9E9A-74B00BC4DADE@ifi.uio.no> 
To: "Michael Ramalho (mramalho)" 
X-Mailer: Apple Mail (2.1283)
X-UiO-SPF-Received: 
X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 2 sum msgs/h 1 total rcpts 11685 max rcpts/h 44 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.146, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 730B7168A70969ACD6970A134220D268131F893D
X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 4184 max/h 16 blacklist 0 greylist 0 ratelimit 0
Cc: rmcat WG 
Subject: Re: [rmcat] Fairness
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jan 2014 08:01:00 -0000

--Apple-Mail=_C94C69A7-0657-4B48-858E-B17C42AA4B6D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

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.



On 16. jan. 2014, at 16:57, Michael Ramalho (mramalho) wrote:

> Michael,
> =20
> While not a commentary on your entire thread, I do have a nit with the =
following sentence in your post:
> =20
> =93Most congestion controls are RTT-dependent, so I guess this is =
something we'll just have to live with.=94
> =20
> 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 =96 =
effectively normalizing out the RTT for the purposes of making the rate =
of increase/decrease appropriate for the RTT it sees.
> =20
> 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 =93the RMCAT =
algorithm=94 WOULD have a control loop rate adjustment that is dependent =
on OWD or RTT.
> =20
> Just because old TCPs dynamics were sensitive to RTT doesn=92t mean =
that we have to propagate that oversight into our work.
> =20
> Best,
> =20
> Michael Ramalho,Ph.D.
> =20

--Apple-Mail=_C94C69A7-0657-4B48-858E-B17C42AA4B6D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

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
<=
div>
(*) 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.



On 16. jan. =
2014, at 16:57, Michael Ramalho (mramalho) wrote:

While =
not a commentary on your entire thread, I do have a nit with the =
following sentence in your post:
=93Most=
 congestion controls are RTT-dependent, so I guess this is something =
we'll just have to live with.=94
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: Just =
because old TCPs dynamics were sensitive to RTT doesn=92t mean that we =
have to propagate that oversight into our =
work.

Thread-Topic: [rmcat] Fairness
Thread-Index: AQHPE77W3F7dpiAyeU+tzhe9lhQMnZqMam1g
Date: Sun, 19 Jan 2014 19:14:30 +0000
Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA31EC1304@ESESSMB205.ericsson.se>
References: <7E50030C-4E5B-4185-9AA8-6AEE50BE1476@netapp.com> <6BF44A6D-215B-4F02-9E9A-74B00BC4DADE@ifi.uio.no>  
In-Reply-To: 
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_81564C0D7D4D2A4B9A86C8C7404A13DA31EC1304ESESSMB205erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvja64yp0ggxO/xS1+nN3JavH+M7/F 6psf2ByYPab83sjqsWTJTyaP1asfMgcwR3HZpKTmZJalFunbJXBlnHp5gKlgYkXFr74WlgbG lowuRk4OCQETiWXHdjNC2GISF+6tZ+ti5OIQEjjEKPFr4UGwhJDAEkaJedulQGw2ARuJlYe+ g8VFBKIlfrw/ywxiMwvISlx/u5MNxBYGsi8e3cAMUSMncWjBU6YuRg4g20ii5ZMqSJhFQFVi 4eI5LCA2r4CvxL6uJ1B7XzBKfP55EyzBKWAnsWLRFnYQmxFo5v3v91ggdolL3HoynwniaAGJ JXvOM0PYohIvH/9jhbCVJBbd/swEUZ8v8ffCWzaIZYISJ2c+YZnAKDoLyahZSMpmISmDiOtI LNj9iQ3C1pZYtvA1M4x95sBjJmTxBYzsqxjZcxMzc9LLjTYxAqPs4JbfqjsY75wTOcQozcGi JM774a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGieOiPsHRJTmsSz++Pjq/eaeDRIpv mCv/xoSaxrj9+fd3GR1scE4UYVeX/VX/LYL3tFffzKqc5OnTP8+SU9Rle3Drj0FgQ66z+nUN NZbrOmuPvNixgn3pwS2n+M9mXZp0tChJ8sa3nw/Yjwk2FF2K23WDxXzJFTaXhpVCQlKHnZMu JnJuzvVXYinOSDTUYi4qTgQAZEOERYACAAA=
Cc: rmcat WG 
Subject: Re: [rmcat] Fairness
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Jan 2014 19:14:50 -0000

--_000_81564C0D7D4D2A4B9A86C8C7404A13DA31EC1304ESESSMB205erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi

A comment on LEDBATs RTT dependency. I may be wrong here but I doubt that L=
EDBAT is RTT independent. The CWND growth function looks to me like Reno wi=
th 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 lo=
nger geographical distance) when I experimented with a LEDBAT like congesti=
on/flow control for realtime interacive media, one possible difference is t=
hat 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 RT=
T dependent, make the CWND function something like
cwnd +=3D GAIN * F(RTT) * off_target * bytes_newly_acked * MSS / cwnd
Where F(RTT) is a function  of RTT, for instance F(RTT) =3D max(0.1,min(1.0=
, RTT/0.3)) and measuring RTT with LEDBAT is a no-brainer.

From: Michael Welzl [mailto:michawe@ifi.uio.no]
Sent: den 17 januari 2014 09:01
To: Michael Ramalho (mramalho)
Cc: rmcat WG
Subject: Re: [rmcat] Fairness

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 betwee=
n 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 don=
e without incorporating the RTT in the gain, when feedback is more than bin=
ary - I did this in my thesis  :-)    (*)

So yes, it's doable and it would be good. But I think that all the 3 curren=
t 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 m=
ake 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.



On 16. jan. 2014, at 16:57, Michael Ramalho (mramalho) wrote:


Michael,

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

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

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

Assuming that our work will eventually have a delay-sensing component, we w=
ill certainly have visibility into the RTT and estimated one way delays (OW=
D). 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 h=
ave to propagate that oversight into our work.

Best,

Michael Ramalho,Ph.D.


--_000_81564C0D7D4D2A4B9A86C8C7404A13DA31EC1304ESESSMB205erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi


 <=
/p>

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 geographi=
cal distance) when I experimented with a LEDBAT like congestion/flow contro=
l 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 CWN=
D function something like



cwnd +=3D GAIN * F(RTT) =
* off_target * bytes_newly_acked * MSS / cwnd


Where F(RTT) is a functio=
n  of RTT, for instance F(RTT) =3D max(0.1,min(1.0, RTT/0.3)) and meas=
uring RTT with LEDBAT is a no-brainer.




 <=
/p>







From: Michael =
Welzl [mailto:michawe@ifi.uio.no]


Sent: den 17 januari 2014 09:01

To: Michael Ramalho (mramalho)

Cc: rmcat WG

Subject: Re: [rmcat] Fairness






 


Hi,




 






I fixed the subject to avoid thread hijacking.<=
/o:p>






 






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 comprom=
ise.






 






Indeed, for full control over fairness, RTT dependen=
ce 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 fe=
edback is more than binary - I did
 this in my thesis  :-)    (*)






 






So yes, it's doable and it would be good. But I thin=
k 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 w=
ay - 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 decreas=
e, 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.






 






 






 






On 16. jan. 2014, at 16:57, Michael Ramalho (mramalh=
o) wrote:















Michael,






 <=
/p>





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






 <=
/p>





“Most congestion co=
ntrols are RTT-dependent, so I guess this is something we'll just have to l=
ive with.”






 <=
/p>





I think this is Chicken a=
nd Egg problem for the RMCAT design. Yes most congestion controls are RTT-d=
ependent. 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 (adapta=
tion)  gain which is RTT-dependent – effectively
 normalizing out the RTT for the purposes of making the rate of increase/de=
crease appropriate for the RTT it sees.






 <=
/p>





Assuming that our work wi=
ll eventually have a delay-sensing component, we will certainly have visibi=
lity into the RTT and estimated one way delays (OWD). Thus
 I think ANY reasonable design of “the RMCAT algorithm” WOULD h=
ave a control loop rate adjustment that is dependent on OWD or RTT.<=
o:p>






 <=
/p>





Just because old TCPs dyn=
amics were sensitive to RTT doesn’t mean that we have to propagate th=
at oversight into our work.






 <=
/p>





Best,





 <=
/p>





Michael Ramalho,Ph.D.






 <=
/p>















--_000_81564C0D7D4D2A4B9A86C8C7404A13DA31EC1304ESESSMB205erics_--

From nicolas.kuhn@telecom-bretagne.eu  Mon Jan 20 00:57:37 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CB11A00AC for ; Mon, 20 Jan 2014 00:57:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.15
X-Spam-Level: *
X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkjnM-Y9xjdt for ; Mon, 20 Jan 2014 00:57:35 -0800 (PST)
Received: from zproxy220.enst-bretagne.fr (zproxy220.enst-bretagne.fr [192.108.117.9]) by ietfa.amsl.com (Postfix) with ESMTP id B3DCD1A00A6 for ; Mon, 20 Jan 2014 00:57:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTP id 70FFC70004; Mon, 20 Jan 2014 09:57:34 +0100 (CET)
X-Virus-Scanned: amavisd-new at zproxy220.enst-bretagne.fr
Received: from zproxy220.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy220.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GWxgibQqLYE; Mon, 20 Jan 2014 09:57:33 +0100 (CET)
Received: from dhcp-salsa-i-129-163.rennes.enst-bretagne.fr (dhcp-salsa-i-129-163.rennes.enst-bretagne.fr [10.35.129.163]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTPSA id 75AED40008; Mon, 20 Jan 2014 09:57:33 +0100 (CET)
Content-Type: multipart/alternative; boundary="Apple-Mail=_282DE5C1-69C0-4F99-B071-6D7B41FFD5CA"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Nicolas KUHN 
In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA31EC1304@ESESSMB205.ericsson.se>
Date: Mon, 20 Jan 2014 09:57:31 +0100
Message-Id: <54E45290-1AA5-4AFF-BFCD-79D8B4EE7BEF@telecom-bretagne.eu>
References: <7E50030C-4E5B-4185-9AA8-6AEE50BE1476@netapp.com> <6BF44A6D-215B-4F02-9E9A-74B00BC4DADE@ifi.uio.no>   <81564C0D7D4D2A4B9A86C8C7404A13DA31EC1304@ESESSMB205.ericsson.se>
To: Ingemar Johansson S 
X-Mailer: Apple Mail (2.1503)
Cc: rmcat WG , "Michael Ramalho \(mramalho\)" , Michael Welzl 
Subject: Re: [rmcat] Fairness
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Jan 2014 08:57:37 -0000

--Apple-Mail=_282DE5C1-69C0-4F99-B071-6D7B41FFD5CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hi=20

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.=20
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.=20

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)=3Dmax(0.1,min(1.0, =
RTT/0.3))) would encounter the same setting problems.=20

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/]

On Jan 19, 2014, at 8:14 PM, Ingemar Johansson S =
 wrote:

> Hi
> =20
> 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 +=3D GAIN * F(RTT) * off_target * bytes_newly_acked * MSS / cwnd
> Where F(RTT) is a function  of RTT, for instance F(RTT) =3D =
max(0.1,min(1.0, RTT/0.3)) and measuring RTT with LEDBAT is a =
no-brainer.
> =20
> From: Michael Welzl [mailto:michawe@ifi.uio.no]=20
> Sent: den 17 januari 2014 09:01
> To: Michael Ramalho (mramalho)
> Cc: rmcat WG
> Subject: Re: [rmcat] Fairness
> =20
> Hi,
> =20
> I fixed the subject to avoid thread hijacking.
> =20
> 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.
> =20
> 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  :-)    (*)
> =20
> So yes, it's doable and it would be good. But I think that all the 3 =
current proposals are RTT-dependant...
> =20
> Cheers,
> Michael
> =20
> (*) 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.
> =20
> =20
> =20
> On 16. jan. 2014, at 16:57, Michael Ramalho (mramalho) wrote:
>=20
>=20
> Michael,
> =20
> While not a commentary on your entire thread, I do have a nit with the =
following sentence in your post:
> =20
> =93Most congestion controls are RTT-dependent, so I guess this is =
something we'll just have to live with.=94
> =20
> 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 =96 =
effectively normalizing out the RTT for the purposes of making the rate =
of increase/decrease appropriate for the RTT it sees.
> =20
> 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 =93the RMCAT =
algorithm=94 WOULD have a control loop rate adjustment that is dependent =
on OWD or RTT.
> =20
> Just because old TCPs dynamics were sensitive to RTT doesn=92t mean =
that we have to propagate that oversight into our work.
> =20
> Best,
> =20
> Michael Ramalho,Ph.D.
> =20


--Apple-Mail=_282DE5C1-69C0-4F99-B071-6D7B41FFD5CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252



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)=3Dmax(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, =
NicolasMehani, OlivierSathiaseelan, ArjunaLochin, Emmanuel Less-than-Best-Effort =
capacity sharing over high BDP networks with LEDBAT [http://oatao.univ-toulouse.f=
r/9196/]

On Jan 19, 2014, at 8:14 PM, Ingemar =
Johansson S <ingemar.s.johansson@erics=
son.com> wrote:

 
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
Where F(RTT) is a function  of RTT, for =
instance F(RTT) =3D max(0.1,min(1.0, RTT/0.3)) and measuring RTT with =
LEDBAT is a no-brainer.
 
 Michael =
Welzl [mailto:michawe@ifi.uio.no] 
Sent: den 17 januari 2014 =
09:01
To: Michael Ramalho =
(mramalho)
Cc: rmcat =
WG
Subject: Re: [rmcat] =
Fairness
I =
fixed the subject to avoid thread =
hijacking.
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.
 
 
 
On 16. jan. 2014, at 16:57, Michael Ramalho =
(mramalho) wrote:
 
While not a commentary =
on your entire thread, I do have a nit with the following sentence in =
your post:
 
=93Most congestion =
controls are RTT-dependent, so I guess this is something we'll just have =
to live with.=94
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:  

In-Reply-To: <54E45290-1AA5-4AFF-BFCD-79D8B4EE7BEF@telecom-bretagne.eu>
Date: Mon, 20 Jan 2014 10:30:05 +0100
Message-Id: <67A76A9B-A9A9-4BE8-85C5-68B77EAAA405@ifi.uio.no>
References: <7E50030C-4E5B-4185-9AA8-6AEE50BE1476@netapp.com> <6BF44A6D-215B-4F02-9E9A-74B00BC4DADE@ifi.uio.no>   <81564C0D7D4D2A4B9A86C8C7404A13DA31EC1304@ESESSMB205.ericsson.se> <54E45290-1AA5-4AFF-BFCD-79D8B4EE7BEF@telecom-bretagne.eu>
To: Nicolas KUHN 
X-Mailer: Apple Mail (2.1283)
X-UiO-SPF-Received: 
X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 3 sum rcpts/h 11 sum msgs/h 6 total rcpts 11748 max rcpts/h 44 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.05, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 2C2772D390EC36C0AAF765F8AA0A0D86132AF0DA
X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 4223 max/h 16 blacklist 0 greylist 0 ratelimit 0
Cc: Ingemar Johansson S , rmcat WG , "Michael Ramalho \(mramalho\)" 
Subject: Re: [rmcat] Fairness
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Jan 2014 09:30:17 -0000

--Apple-Mail=_0BBA3B52-169E-4DC7-BDA8-B7FB310AEC67
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

+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!


On 20. jan. 2014, at 09:57, Nicolas KUHN wrote:

> Hi=20
>=20
> 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.=20
> 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.=20
>=20
> 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)=3Dmax(0.1,min(1.0, =
RTT/0.3))) would encounter the same setting problems.=20
>=20
> I believe efforts should not be done towards improvements in the CWND =
evolution, but in changing LEDBAT's algorithm.
>=20
> Nicolas KUHN
>=20
> [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/]
>=20
> On Jan 19, 2014, at 8:14 PM, Ingemar Johansson S =
 wrote:
>=20
>> Hi
>> =20
>> 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 +=3D GAIN * F(RTT) * off_target * bytes_newly_acked * MSS / cwnd
>> Where F(RTT) is a function  of RTT, for instance F(RTT) =3D =
max(0.1,min(1.0, RTT/0.3)) and measuring RTT with LEDBAT is a =
no-brainer.
>> =20
>> From: Michael Welzl [mailto:michawe@ifi.uio.no]=20
>> Sent: den 17 januari 2014 09:01
>> To: Michael Ramalho (mramalho)
>> Cc: rmcat WG
>> Subject: Re: [rmcat] Fairness
>> =20
>> Hi,
>> =20
>> I fixed the subject to avoid thread hijacking.
>> =20
>> 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.
>> =20
>> 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  :-)    (*)
>> =20
>> So yes, it's doable and it would be good. But I think that all the 3 =
current proposals are RTT-dependant...
>> =20
>> Cheers,
>> Michael
>> =20
>> (*) 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.
>> =20
>> =20
>> =20
>> On 16. jan. 2014, at 16:57, Michael Ramalho (mramalho) wrote:
>>=20
>>=20
>> Michael,
>> =20
>> While not a commentary on your entire thread, I do have a nit with =
the following sentence in your post:
>> =20
>> =93Most congestion controls are RTT-dependent, so I guess this is =
something we'll just have to live with.=94
>> =20
>> 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 =96 =
effectively normalizing out the RTT for the purposes of making the rate =
of increase/decrease appropriate for the RTT it sees.
>> =20
>> 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 =93the RMCAT =
algorithm=94 WOULD have a control loop rate adjustment that is dependent =
on OWD or RTT.
>> =20
>> Just because old TCPs dynamics were sensitive to RTT doesn=92t mean =
that we have to propagate that oversight into our work.
>> =20
>> Best,
>> =20
>> Michael Ramalho,Ph.D.
>> =20
>=20


--Apple-Mail=_0BBA3B52-169E-4DC7-BDA8-B7FB310AEC67
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

+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!


On 20. jan. 2014, at 09:57, =
Nicolas KUHN wrote:

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)=3Dmax(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.

On Jan 19, 2014, at 8:14 PM, Ingemar =
Johansson S <ingemar.s.johansson@erics=
son.com> wrote:

 
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
Where F(RTT) is a function  of RTT, for =
instance F(RTT) =3D max(0.1,min(1.0, RTT/0.3)) and measuring RTT with =
LEDBAT is a no-brainer.
 
 Michael =
Welzl [mailto:michawe@ifi.uio.no] 
Sent: den 17 januari 2014 =
09:01
To: Michael Ramalho =
(mramalho)
Cc: rmcat =
WG
Subject: Re: [rmcat] =
Fairness
I =
fixed the subject to avoid thread =
hijacking.
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.
 
 
 
On 16. jan. 2014, at 16:57, Michael Ramalho =
(mramalho) wrote:
 
While not a commentary =
on your entire thread, I do have a nit with the following sentence in =
your post:
 
=93Most congestion =
controls are RTT-dependent, so I guess this is something we'll just have =
to live with.=94
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:  
, "Michael Ramalho \(mramalho\)" 
Subject: Re: [rmcat] Fairness
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Jan 2014 09:42:23 -0000

--_000_81564C0D7D4D2A4B9A86C8C7404A13DA31EC15EBESESSMB205erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi

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

/Ingemar

From: Michael Welzl [mailto:michawe@ifi.uio.no]
Sent: den 20 januari 2014 10:30
To: Nicolas KUHN
Cc: Ingemar Johansson S; Michael Ramalho (mramalho); rmcat WG
Subject: Re: [rmcat] Fairness

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

I think this group has decided long ago that it doesn't want to work with L=
EDBAT 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!


On 20. jan. 2014, at 09:57, Nicolas KUHN wrote:


Hi

The GAIN parameter embodies LEDBAT's capability to react dynamically with O=
WD 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 shar=
ing 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 depende=
ncy 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)=3Dmax(0.1,min(1.0, RTT/0.3))) would encounter the same se=
tting problems.

I believe efforts should not be done towards improvements in the CWND evolu=
tion, 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/]

On Jan 19, 2014, at 8:14 PM, Ingemar Johansson S > wrote:


Hi

A comment on LEDBATs RTT dependency. I may be wrong here but I doubt that L=
EDBAT is RTT independent. The CWND growth function looks to me like Reno wi=
th 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 lo=
nger geographical distance) when I experimented with a LEDBAT like congesti=
on/flow control for realtime interacive media, one possible difference is t=
hat 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 RT=
T dependent, make the CWND function something like
cwnd +=3D GAIN * F(RTT) * off_target * bytes_newly_acked * MSS / cwnd
Where F(RTT) is a function  of RTT, for instance F(RTT) =3D max(0.1,min(1.0=
, RTT/0.3)) and measuring RTT with LEDBAT is a no-brainer.

From: Michael Welzl [mailto:michawe@ifi.uio.no]
Sent: den 17 januari 2014 09:01
To: Michael Ramalho (mramalho)
Cc: rmcat WG
Subject: Re: [rmcat] Fairness

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 betwee=
n 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 don=
e without incorporating the RTT in the gain, when feedback is more than bin=
ary - I did this in my thesis  :-)    (*)

So yes, it's doable and it would be good. But I think that all the 3 curren=
t 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 m=
ake 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.



On 16. jan. 2014, at 16:57, Michael Ramalho (mramalho) wrote:



Michael,

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

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

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

Assuming that our work will eventually have a delay-sensing component, we w=
ill certainly have visibility into the RTT and estimated one way delays (OW=
D). 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 h=
ave to propagate that oversight into our work.

Best,

Michael Ramalho,Ph.D.




--_000_81564C0D7D4D2A4B9A86C8C7404A13DA31EC15EBESESSMB205erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi


 <=
/p>

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


 <=
/p>

/Ingemar


 <=
/p>







From: Michael =
Welzl [mailto:michawe@ifi.uio.no]


Sent: den 20 januari 2014 10:30

To: Nicolas KUHN

Cc: Ingemar Johansson S; Michael Ramalho (mramalho); rmcat WG

Subject: Re: [rmcat] Fairness






 


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




 






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




 






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






 






 






On 20. jan. 2014, at 09:57, Nicolas KUHN wrote:=
















Hi 






 






The GAIN parameter embodies LEDBAT's capability to r=
eact dynamically with OWD fluctuations. I believe that this reactivity (whi=
ch is one key behaviour of LEDBAT) is linked to the gain, but to the RTT va=
lue 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, LEDB=
AT would probably react slower than the TCP connexion
 to the congestion events, and LEDBAT would not have a less-than-best-effor=
t behaviour. According to me, this justify that the RTT's dependency o=
f 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)=3Dmax(0.1,min(1.0, RTT/0.3))) would encounter the same setting probl=
ems. 






 






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







 






Nicolas KUHN






 






[0] David Ros, Michael Welzl: Assessing LEDBAT's Del=
ay Impact.





 
















Hi






 <=
/p>





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 geographi=
cal distance) when I experimented with a LEDBAT like congestion/flow contro=
l 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 CWN=
D function something like






cwnd +=3D GAIN * F(RTT) * off_target=
 * bytes_newly_acked * MSS / cwnd






Where F(RTT) is a functio=
n  of RTT, for instance F(RTT) =3D max(0.1,min(1.0, RTT/0.3)) and meas=
uring RTT with LEDBAT is a no-brainer.






 <=
/p>











From: Michael
 Welzl [mailto:michawe@ifi.uio.no] <=
/span>

Sent: den 17 janua=
ri 2014 09:01

To: Michael Ramalh=
o (mramalho)

Cc: rmcat WG

Subject: Re: [rmca=
t] Fairness










 






Hi,








 










I fixed the subject to avoid thread hijacking.<=
/o:p>










 










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 comprom=
ise.










 










Indeed, for full control over fairness, RTT dependen=
ce 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 fe=
edback is more than binary - I did
 this in my thesis  :-)    (*)










 










So yes, it's doable and it would be good. But I thin=
k 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 w=
ay - 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 decreas=
e, 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.










 










 










 










On 16. jan. 2014, at 16:57, Michael Ramalho (mramalh=
o) wrote:

























Michael,










 <=
/p>









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










 <=
/p>









“Most congestion co=
ntrols are RTT-dependent, so I guess this is something we'll just have to l=
ive with.”










 <=
/p>









I think this is Chicken a=
nd Egg problem for the RMCAT design. Yes most congestion controls are RTT-d=
ependent. But newer CCs (e.g., FAST TCP, see equation 1
 at: http://netlab.caltech.edu/publications/fast-network05.pdf) h=
ave 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 i=
t sees.










 <=
/p>









Assuming that our work wi=
ll eventually have a delay-sensing component, we will certainly have visibi=
lity into the RTT and estimated one way delays (OWD). Thus
 I think ANY reasonable design of “the RMCAT algorithm” WOULD h=
ave a control loop rate adjustment that is dependent on OWD or RTT.<=
o:p>










 <=
/p>









Just because old TCPs dyn=
amics were sensitive to RTT doesn’t mean that we have to propagate th=
at oversight into our work.










 <=
/p>









Best,









 <=
/p>









Michael Ramalho,Ph.D.










 <=
/p>

















 






 












--_000_81564C0D7D4D2A4B9A86C8C7404A13DA31EC15EBESESSMB205erics_--

From michawe@ifi.uio.no  Mon Jan 20 01:50:06 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0EBE1A00BC for ; Mon, 20 Jan 2014 01:50:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.434
X-Spam-Level: 
X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QT-3plWTTcQp for ; Mon, 20 Jan 2014 01:50:03 -0800 (PST)
Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id B168E1A00BB for ; Mon, 20 Jan 2014 01:50:02 -0800 (PST)
Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1W5BUU-0002cl-MS; Mon, 20 Jan 2014 10:49:58 +0100
Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1W5BUT-0002LB-69; Mon, 20 Jan 2014 10:49:58 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_F8D38FC7-348B-4CCF-A7FF-AF2F4ED9E0A6"
From: Michael Welzl 
In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA31EC15EB@ESESSMB205.ericsson.se>
Date: Mon, 20 Jan 2014 10:49:56 +0100
Message-Id: 
References: <7E50030C-4E5B-4185-9AA8-6AEE50BE1476@netapp.com> <6BF44A6D-215B-4F02-9E9A-74B00BC4DADE@ifi.uio.no>   <81564C0D7D4D2A4B9A86C8C7404A13DA31EC1304@ESESSMB205.ericsson.se> <54E45290-1AA5-4AFF-BFCD-79D8B4EE7BEF@telecom-bretagne.eu> <67A76A9B-A9A9-4BE8-85C5-68B77EAAA405@ifi.uio.no> <81564C0D7D4D2A4B9A86C8C7404A13DA31EC15EB@ESESSMB205.ericsson.se>
To: Ingemar Johansson S 
X-Mailer: Apple Mail (2.1283)
X-UiO-SPF-Received: 
X-UiO-Ratelimit-Test: rcpts/h 13 msgs/h 5 sum rcpts/h 17 sum msgs/h 8 total rcpts 11754 max rcpts/h 44 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.05, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 3B988FCDC8B13C5BF467EB158EF3E1C5852D9AB1
X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 4225 max/h 16 blacklist 0 greylist 0 ratelimit 0
Cc: rmcat WG , Nicolas KUHN , "Michael Ramalho \(mramalho\)" 
Subject: Re: [rmcat] Fairness
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Jan 2014 09:50:07 -0000

--Apple-Mail=_F8D38FC7-348B-4CCF-A7FF-AF2F4ED9E0A6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

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


On 20. jan. 2014, at 10:42, Ingemar Johansson S wrote:

> Hi
> =20
> I have probably missed this, but when was it decided that the group =
does not want to work on LEDBAT ?
> =20
> /Ingemar
> =20
> From: Michael Welzl [mailto:michawe@ifi.uio.no]=20
> Sent: den 20 januari 2014 10:30
> To: Nicolas KUHN
> Cc: Ingemar Johansson S; Michael Ramalho (mramalho); rmcat WG
> Subject: Re: [rmcat] Fairness
> =20
> +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.
> =20
> I think this group has decided long ago that it doesn't want to work =
with LEDBAT but with a new scheme.
> =20
> Getting back to the main issue at hand: can we require =
RTT-independence? I'd like to, if indeed we can!
> =20
> =20
> On 20. jan. 2014, at 09:57, Nicolas KUHN wrote:
>=20
>=20
> Hi=20
> =20
> 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.=20
> 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.=20
> =20
> 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)=3Dmax(0.1,min(1.0, =
RTT/0.3))) would encounter the same setting problems.=20
> =20
> I believe efforts should not be done towards improvements in the CWND =
evolution, but in changing LEDBAT's algorithm.
> =20
> Nicolas KUHN
> =20
> [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/]
> =20
> On Jan 19, 2014, at 8:14 PM, Ingemar Johansson S =
 wrote:
>=20
>=20
> Hi
> =20
> 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 +=3D GAIN * F(RTT) * off_target * bytes_newly_acked * MSS / cwnd
> Where F(RTT) is a function  of RTT, for instance F(RTT) =3D =
max(0.1,min(1.0, RTT/0.3)) and measuring RTT with LEDBAT is a =
no-brainer.
> =20
> From: Michael Welzl [mailto:michawe@ifi.uio.no]=20
> Sent: den 17 januari 2014 09:01
> To: Michael Ramalho (mramalho)
> Cc: rmcat WG
> Subject: Re: [rmcat] Fairness
> =20
> Hi,
> =20
> I fixed the subject to avoid thread hijacking.
> =20
> 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.
> =20
> 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  :-)    (*)
> =20
> So yes, it's doable and it would be good. But I think that all the 3 =
current proposals are RTT-dependant...
> =20
> Cheers,
> Michael
> =20
> (*) 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.
> =20
> =20
> =20
> On 16. jan. 2014, at 16:57, Michael Ramalho (mramalho) wrote:
>=20
>=20
>=20
> Michael,
> =20
> While not a commentary on your entire thread, I do have a nit with the =
following sentence in your post:
> =20
> =93Most congestion controls are RTT-dependent, so I guess this is =
something we'll just have to live with.=94
> =20
> 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 =96 =
effectively normalizing out the RTT for the purposes of making the rate =
of increase/decrease appropriate for the RTT it sees.
> =20
> 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 =93the RMCAT =
algorithm=94 WOULD have a control loop rate adjustment that is dependent =
on OWD or RTT.
> =20
> Just because old TCPs dynamics were sensitive to RTT doesn=92t mean =
that we have to propagate that oversight into our work.
> =20
> Best,
> =20
> Michael Ramalho,Ph.D.
> =20
> =20


--Apple-Mail=_F8D38FC7-348B-4CCF-A7FF-AF2F4ED9E0A6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

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

=


On 20. jan. 2014, at 10:42, Ingemar =
Johansson S wrote:

I =
have probably missed this, but when was it decided that the group does =
not want to work on LEDBAT ?
 Michael =
Welzl [mailto:michawe@ifi.uio.no] 
Sent: den 20 januari 2014 =
10:30
To: Nicolas =
KUHN
Cc: Ingemar Johansson S; =
Michael Ramalho (mramalho); rmcat WG
Subject: Re: [rmcat] =
Fairness
+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!
On 20. jan. 2014, at =
09:57, Nicolas KUHN wrote:
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)=3Dmax(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, NicolasMehani, =
Olivier and Sathiaseelan, =
Arjuna and Lochin, =
Emmanuel  
On Jan 19, 2014, at 8:14 PM, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> =
wrote:
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 +=3D GAIN * F(RTT) * =
off_target * bytes_newly_acked * MSS / =
cwnd
Where =
F(RTT) is a function  of RTT, for instance F(RTT) =3D =
max(0.1,min(1.0, RTT/0.3)) and measuring RTT with LEDBAT is a =
no-brainer.
 
, Nicolas KUHN , "Michael Ramalho \(mramalho\)" 
Subject: Re: [rmcat] Fairness
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Jan 2014 09:58:40 -0000

--_000_81564C0D7D4D2A4B9A86C8C7404A13DA31EC1654ESESSMB205erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

OK, then I understand, thanks

/Ingemar

From: Michael Welzl [mailto:michawe@ifi.uio.no]
Sent: den 20 januari 2014 10:50
To: Ingemar Johansson S
Cc: Nicolas KUHN; Michael Ramalho (mramalho); rmcat WG
Subject: Re: [rmcat] Fairness

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 an=
d very early on in the mailing list (before the group really came into bein=
g, I think)

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

Cheers,
Michael


On 20. jan. 2014, at 10:42, Ingemar Johansson S wrote:


Hi

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

/Ingemar

From: Michael Welzl [mailto:michawe@ifi.uio.no]
Sent: den 20 januari 2014 10:30
To: Nicolas KUHN
Cc: Ingemar Johansson S; Michael Ramalho (mramalho); rmcat WG
Subject: Re: [rmcat] Fairness

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

I think this group has decided long ago that it doesn't want to work with L=
EDBAT 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!


On 20. jan. 2014, at 09:57, Nicolas KUHN wrote:



Hi

The GAIN parameter embodies LEDBAT's capability to react dynamically with O=
WD 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 shar=
ing 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 depende=
ncy 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)=3Dmax(0.1,min(1.0, RTT/0.3))) would encounter the same se=
tting problems.

I believe efforts should not be done towards improvements in the CWND evolu=
tion, 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/]

On Jan 19, 2014, at 8:14 PM, Ingemar Johansson S > wrote:



Hi

A comment on LEDBATs RTT dependency. I may be wrong here but I doubt that L=
EDBAT is RTT independent. The CWND growth function looks to me like Reno wi=
th 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 lo=
nger geographical distance) when I experimented with a LEDBAT like congesti=
on/flow control for realtime interacive media, one possible difference is t=
hat 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 RT=
T dependent, make the CWND function something like
cwnd +=3D GAIN * F(RTT) * off_target * bytes_newly_acked * MSS / cwnd
Where F(RTT) is a function  of RTT, for instance F(RTT) =3D max(0.1,min(1.0=
, RTT/0.3)) and measuring RTT with LEDBAT is a no-brainer.

From: Michael Welzl [mailto:michawe@ifi.uio.no]
Sent: den 17 januari 2014 09:01
To: Michael Ramalho (mramalho)
Cc: rmcat WG
Subject: Re: [rmcat] Fairness

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 betwee=
n 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 don=
e without incorporating the RTT in the gain, when feedback is more than bin=
ary - I did this in my thesis  :-)    (*)

So yes, it's doable and it would be good. But I think that all the 3 curren=
t 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 m=
ake 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.



On 16. jan. 2014, at 16:57, Michael Ramalho (mramalho) wrote:




Michael,

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

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

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

Assuming that our work will eventually have a delay-sensing component, we w=
ill certainly have visibility into the RTT and estimated one way delays (OW=
D). 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 h=
ave to propagate that oversight into our work.

Best,

Michael Ramalho,Ph.D.




--_000_81564C0D7D4D2A4B9A86C8C7404A13DA31EC1654ESESSMB205erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











OK, then I understand, th=
anks


 <=
/p>

/Ingemar


 <=
/p>







From: Michael =
Welzl [mailto:michawe@ifi.uio.no]


Sent: den 20 januari 2014 10:50

To: Ingemar Johansson S

Cc: Nicolas KUHN; Michael Ramalho (mramalho); rmcat WG

Subject: Re: [rmcat] Fairness






 


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




 






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






 






2) nobody has yet proposed it as a mechanism for RMC=
AT...






 






Cheers,






Michael






 






 








On 20. jan. 2014, at 10:42, Ingemar Johansson S wrot=
e:















Hi






 <=
/p>





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






 <=
/p>





/Ingemar






 <=
/p>








 






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








 










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








 










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










 










 










On 20. jan. 2014, at 09:57, Nicolas KUHN wrote:=


























Hi 










 










The GAIN parameter embodies LEDBAT's capability to r=
eact dynamically with OWD fluctuations. I believe that this reactivity (whi=
ch is one key behaviour of LEDBAT) is linked to the gain, but to the RTT va=
lue 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, LEDB=
AT would probably react slower than the TCP connexion
 to the congestion events, and LEDBAT would not have a less-than-best-effor=
t behaviour. According to me, this justify that the RTT's dependency o=
f 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)=3Dmax(0.1,min(1.0, RTT/0.3))) would encounter the same setting probl=
ems. 










 










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











 










Nicolas KUHN










 










[0] David Ros, Michael Welzl: Assessing LEDBAT's Del=
ay Impact.









 










On Jan 19, 2014, at 8:14 PM, Ingemar Johansson S <=
;ingemar.s.johansson@er=
icsson.com> wrote:

























Hi










 <=
/p>









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 geographi=
cal distance) when I experimented with a LEDBAT like congestion/flow contro=
l 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 CWN=
D function something like










cwnd +=3D GAIN * F(RTT) * off_target=
 * bytes_newly_acked * MSS / cwnd










Where F(RTT) is a functio=
n  of RTT, for instance F(RTT) =3D max(0.1,min(1.0, RTT/0.3)) and meas=
uring RTT with LEDBAT is a no-brainer.










 <=
/p>















From: Michael
 Welzl [mailto:michawe@ifi.uio.no] <=
/span>

Sent: den 17 janua=
ri 2014 09:01

To: Michael Ramalh=
o (mramalho)

Cc: rmcat WG

Subject: Re: [rmca=
t] Fairness














 










Hi,












 














I fixed the subject to avoid thread hijacking.<=
/o:p>














 














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 comprom=
ise.














 














Indeed, for full control over fairness, RTT dependen=
ce 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 fe=
edback is more than binary - I did
 this in my thesis  :-)    (*)














 














So yes, it's doable and it would be good. But I thin=
k 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 w=
ay - 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 decreas=
e, 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.














 














 














 














On 16. jan. 2014, at 16:57, Michael Ramalho (mramalh=
o) wrote:



































Michael,














 <=
/p>













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














 <=
/p>













“Most congestion co=
ntrols are RTT-dependent, so I guess this is something we'll just have to l=
ive with.”














 <=
/p>













I think this is Chicken a=
nd Egg problem for the RMCAT design. Yes most congestion controls are RTT-d=
ependent. But newer CCs (e.g., FAST TCP, see equation 1
 at: http://netlab.caltech.edu/publications/fast-network05.pdf) h=
ave 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 i=
t sees.














 <=
/p>













Assuming that our work wi=
ll eventually have a delay-sensing component, we will certainly have visibi=
lity into the RTT and estimated one way delays (OWD). Thus
 I think ANY reasonable design of “the RMCAT algorithm” WOULD h=
ave a control loop rate adjustment that is dependent on OWD or RTT.<=
o:p>














 <=
/p>













Just because old TCPs dyn=
amics were sensitive to RTT doesn’t mean that we have to propagate th=
at oversight into our work.














 <=
/p>













Best,













 <=
/p>













Michael Ramalho,Ph.D.














 <=
/p>





















 


















 












--_000_81564C0D7D4D2A4B9A86C8C7404A13DA31EC1654ESESSMB205erics_--

From mramalho@cisco.com  Mon Jan 20 06:22:54 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB7E1A0180 for ; Mon, 20 Jan 2014 06:22:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.035
X-Spam-Level: 
X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQojKW2k8Qfm for ; Mon, 20 Jan 2014 06:22:49 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFF21A0196 for ; Mon, 20 Jan 2014 06:22:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38243; q=dns/txt; s=iport; t=1390227769; x=1391437369; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=s813O83ijVlhjxipZ6993Mbh5DphQ0/Cupo34k6sr6U=; b=cuIJP0zlea4fZ17YLKaiNMnYTnzn6C1Sg61X5oGGnpX1XgJb9O4m/6LT HI5SKpAALPSgpkcsFXOtr94dx3s4xrTDrtvn4mF8Os6h3Z8nWaTM9uKDD V8ihLmsKBwQM6AVUnue685n7pH7KdraEJ4jTWDyMrib9tPs8doWU+7eYS A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AugHAOgv3VKtJXG8/2dsb2JhbABZgkdEOFaya4hRgQ0WdIIlAQEBAgItPwIIAxACAQgRBAEBCxYBBgcyFAkIAgQBDQUIh30Nw1QXjk4xBgEJgxuBFASZVJBmgy2CKg
X-IronPort-AV: E=Sophos;i="4.95,691,1384300800"; d="scan'208,217";a="14132076"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-4.cisco.com with ESMTP; 20 Jan 2014 14:22:47 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0KEMl7u031772 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Jan 2014 14:22:47 GMT
Received: from xmb-rcd-x12.cisco.com ([169.254.2.37]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Mon, 20 Jan 2014 08:22:47 -0600
From: "Michael Ramalho (mramalho)" 
To: Ingemar Johansson S , Michael Welzl 
Thread-Topic: [rmcat] Fairness
Thread-Index: AQHPE1o+dkVdHFGIiUCG1v1apdg4UZqM0zsAgADl84CAAAkZgIAAA2gAgAACJACAAAJIAP//3YLg
Date: Mon, 20 Jan 2014 14:22:47 +0000
Message-ID: 
References: <7E50030C-4E5B-4185-9AA8-6AEE50BE1476@netapp.com> <6BF44A6D-215B-4F02-9E9A-74B00BC4DADE@ifi.uio.no>   <81564C0D7D4D2A4B9A86C8C7404A13DA31EC1304@ESESSMB205.ericsson.se> <54E45290-1AA5-4AFF-BFCD-79D8B4EE7BEF@telecom-bretagne.eu> <67A76A9B-A9A9-4BE8-85C5-68B77EAAA405@ifi.uio.no> <81564C0D7D4D2A4B9A86C8C7404A13DA31EC15EB@ESESSMB205.ericsson.se>  <81564C0D7D4D2A4B9A86C8C7404A13DA31EC1654@ESESSMB205.ericsson.se>
In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA31EC1654@ESESSMB205.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.117.125.231]
Content-Type: multipart/alternative; boundary="_000_D21571530BF9644D9A443D6BD95B910323000728xmbrcdx12ciscoc_"
MIME-Version: 1.0
Cc: rmcat WG , Nicolas KUHN 
Subject: Re: [rmcat] Fairness
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Jan 2014 14:22:55 -0000

--_000_D21571530BF9644D9A443D6BD95B910323000728xmbrcdx12ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

[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 tha=
n 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 e=
valuation experiments. This was primarily to make sure some weird interacti=
on 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 w=
hat 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 DESIGNE=
D to be a function of the RTT. My understanding was that this was done so t=
hat long-RTT flows were not disadvantaged by short-RTT flows.

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

Thus, it is my hope that any resulting RMCAT adaptation algorithm has accom=
modation 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 ori=
ginal 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 (an=
d that I didn't open up a new can of worms).

Michael Ramalho, Ph.D.

From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com]
Sent: Monday, January 20, 2014 4:58 AM
To: Michael Welzl
Cc: Nicolas KUHN; Michael Ramalho (mramalho); rmcat WG
Subject: RE: [rmcat] Fairness

OK, then I understand, thanks

/Ingemar

From: Michael Welzl [mailto:michawe@ifi.uio.no]
Sent: den 20 januari 2014 10:50
To: Ingemar Johansson S
Cc: Nicolas KUHN; Michael Ramalho (mramalho); rmcat WG
Subject: Re: [rmcat] Fairness

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 an=
d very early on in the mailing list (before the group really came into bein=
g, I think)

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

Cheers,
Michael


On 20. jan. 2014, at 10:42, Ingemar Johansson S wrote:

Hi

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

/Ingemar

From: Michael Welzl [mailto:michawe@ifi.uio.no]
Sent: den 20 januari 2014 10:30
To: Nicolas KUHN
Cc: Ingemar Johansson S; Michael Ramalho (mramalho); rmcat WG
Subject: Re: [rmcat] Fairness

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

I think this group has decided long ago that it doesn't want to work with L=
EDBAT 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!


On 20. jan. 2014, at 09:57, Nicolas KUHN wrote:


Hi

The GAIN parameter embodies LEDBAT's capability to react dynamically with O=
WD 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 shar=
ing 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 depende=
ncy 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)=3Dmax(0.1,min(1.0, RTT/0.3))) would encounter the same se=
tting problems.

I believe efforts should not be done towards improvements in the CWND evolu=
tion, 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/]

On Jan 19, 2014, at 8:14 PM, Ingemar Johansson S > wrote:


Hi

A comment on LEDBATs RTT dependency. I may be wrong here but I doubt that L=
EDBAT is RTT independent. The CWND growth function looks to me like Reno wi=
th 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 lo=
nger geographical distance) when I experimented with a LEDBAT like congesti=
on/flow control for realtime interacive media, one possible difference is t=
hat 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 RT=
T dependent, make the CWND function something like
cwnd +=3D GAIN * F(RTT) * off_target * bytes_newly_acked * MSS / cwnd
Where F(RTT) is a function  of RTT, for instance F(RTT) =3D max(0.1,min(1.0=
, RTT/0.3)) and measuring RTT with LEDBAT is a no-brainer.

From: Michael Welzl [mailto:michawe@ifi.uio.no]
Sent: den 17 januari 2014 09:01
To: Michael Ramalho (mramalho)
Cc: rmcat WG
Subject: Re: [rmcat] Fairness

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 betwee=
n 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 don=
e without incorporating the RTT in the gain, when feedback is more than bin=
ary - I did this in my thesis  :-)    (*)

So yes, it's doable and it would be good. But I think that all the 3 curren=
t 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 m=
ake 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.



On 16. jan. 2014, at 16:57, Michael Ramalho (mramalho) wrote:



Michael,

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

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

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

Assuming that our work will eventually have a delay-sensing component, we w=
ill certainly have visibility into the RTT and estimated one way delays (OW=
D). 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 h=
ave to propagate that oversight into our work.

Best,

Michael Ramalho,Ph.D.




--_000_D21571530BF9644D9A443D6BD95B910323000728xmbrcdx12ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











[Jeez, thanks Michael Wel=
zl for this thread.]


 <=
/p>

Re: LEDBAT & RMCAT


 <=
/p>

During the design team me=
etings, the members assumed that LEDBAT transport was targeted toward a low=
er-than-best-effort AND likely less aggressive than our
 real-time transport needs.


 <=
/p>

Although there was no ser=
ious 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 no=
t 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 fl=
ows to (thanks Nicolas ;-) ).


 <=
/p>

Re: RMCAT & RTT-depen=
dence/independence


 <=
/p>

This part of the thread b=
egan 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 lon=
g-RTT flows were not disadvantaged by short-RTT flows.

 <=
/p>

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


 <=
/p>

Thus, it is my hope that =
any resulting RMCAT adaptation algorithm has accommodation for adaptation b=
y 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 co=
mmentary.


 <=
/p>

Summary:


 <=
/p>

I hope that the above put=
s all the commentary of this thread in context (and that I didn’t ope=
n up a new can of worms).


 <=
/p>

Michael Ramalho, Ph.D.


 <=
/p>





From: Ingemar =
Johansson S [mailto:ingemar.s.johansson@ericsson.com]


Sent: Monday, January 20, 2014 4:58 AM

To: Michael Welzl

Cc: Nicolas KUHN; Michael Ramalho (mramalho); rmcat WG

Subject: RE: [rmcat] Fairness






 


OK, then I understand, th=
anks


 <=
/p>

/Ingemar


 <=
/p>







From: Michael =
Welzl [mailto:michawe@ifi.uio.no]


Sent: den 20 januari 2014 10:50

To: Ingemar Johansson S

Cc: Nicolas KUHN; Michael Ramalho (mramalho); rmcat WG

Subject: Re: [rmcat] Fairness






 


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




 






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






 






2) nobody has yet proposed it as a mechanism for RMC=
AT...






 






Cheers,






Michael






 






 








On 20. jan. 2014, at 10:42, Ingemar Johansson S wrot=
e:




 






Hi






 <=
/p>





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






 <=
/p>





/Ingemar






 <=
/p>











From: Michael
 Welzl [mailto:michawe@ifi.uio.no=
] 

Sent: den 20 janua=
ri 2014 10:30

To: Nicolas KUHN
Cc: Ingemar Johans=
son S; Michael Ramalho (mramalho); rmcat WG

Subject: Re: [rmca=
t] Fairness










 






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








 










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








 










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










 










 










On 20. jan. 2014, at 09:57, Nicolas KUHN wrote:=
























Hi 










 










The GAIN parameter embodies LEDBAT's capability to r=
eact dynamically with OWD fluctuations. I believe that this reactivity (whi=
ch is one key behaviour of LEDBAT) is linked to the gain, but to the RTT va=
lue 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, LEDB=
AT would probably react slower than the TCP connexion
 to the congestion events, and LEDBAT would not have a less-than-best-effor=
t behaviour. According to me, this justify that the RTT's dependency o=
f 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)=3Dmax(0.1,min(1.0, RTT/0.3))) would encounter the same setting probl=
ems. 










 










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











 










Nicolas KUHN










 










[0] David Ros, Michael Welzl: Assessing LEDBAT's Del=
ay Impact.










[1] Kuhn, Nicolas an=
d Mehani,
 Olivier and Sathiaseelan, Arju=
na and Lochin, Emmanuel&=
nbsp;Less-than-Best-Effort capacity sharing over high BDP networks with LEDBA=
T [ht=
tp://oatao.univ-toulouse.fr/9196/]








 










On Jan 19, 2014, at 8:14 PM, Ingemar Johansson S <=
;ingemar.s.johansson@er=
icsson.com> wrote:























Hi










 <=
/p>









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 geographi=
cal distance) when I experimented with a LEDBAT like congestion/flow contro=
l 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 CWN=
D function something like










cwnd +=3D GAIN * F(RTT) * off_target=
 * bytes_newly_acked * MSS / cwnd










Where F(RTT) is a functio=
n  of RTT, for instance F(RTT) =3D max(0.1,min(1.0, RTT/0.3)) and meas=
uring RTT with LEDBAT is a no-brainer.










 <=
/p>















From: Michael
 Welzl [mailto:michawe@ifi.uio.no] <=
/span>

Sent: den 17 janua=
ri 2014 09:01

To: Michael Ramalh=
o (mramalho)

Cc: rmcat WG

Subject: Re: [rmca=
t] Fairness














 










Hi,












 














I fixed the subject to avoid thread hijacking.<=
/o:p>














 














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 comprom=
ise.














 














Indeed, for full control over fairness, RTT dependen=
ce 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 fe=
edback is more than binary - I did
 this in my thesis  :-)    (*)














 














So yes, it's doable and it would be good. But I thin=
k 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 w=
ay - 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 decreas=
e, 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.














 














 














 














On 16. jan. 2014, at 16:57, Michael Ramalho (mramalh=
o) wrote:

































Michael,














 <=
/p>













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














 <=
/p>













“Most congestion co=
ntrols are RTT-dependent, so I guess this is something we'll just have to l=
ive with.”














 <=
/p>













I think this is Chicken a=
nd Egg problem for the RMCAT design. Yes most congestion controls are RTT-d=
ependent. But newer CCs (e.g., FAST TCP, see equation 1
 at: http://netlab.caltech.edu/publications/fast-network05.pdf) h=
ave 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 i=
t sees.














 <=
/p>













Assuming that our work wi=
ll eventually have a delay-sensing component, we will certainly have visibi=
lity into the RTT and estimated one way delays (OWD). Thus
 I think ANY reasonable design of “the RMCAT algorithm” WOULD h=
ave a control loop rate adjustment that is dependent on OWD or RTT.<=
o:p>














 <=
/p>













Just because old TCPs dyn=
amics were sensitive to RTT doesn’t mean that we have to propagate th=
at oversight into our work.














 <=
/p>













Best,













 <=
/p>













Michael Ramalho,Ph.D.














 <=
/p>





















 


















 












--_000_D21571530BF9644D9A443D6BD95B910323000728xmbrcdx12ciscoc_--


From lars@netapp.com  Tue Jan 21 04:53:50 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7811A00E9 for ; Tue, 21 Jan 2014 04:53:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKcE0quhTdEU for ; Tue, 21 Jan 2014 04:53:49 -0800 (PST)
Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED8F1A010C for ; Tue, 21 Jan 2014 04:53:49 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.95,696,1384329600";  d="asc'?scan'208";a="97220181"
Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx11-out.netapp.com with ESMTP; 21 Jan 2014 04:53:49 -0800
Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 04:53:49 -0800
From: "Eggert, Lars" 
To: rmcat WG 
Thread-Topic: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
Thread-Index: AQHPEpYXwCGFx0stw0qE8XczVDv3zJqH8DYAgAfAX4A=
Importance: high
X-Priority: 1
Date: Tue, 21 Jan 2014 12:53:48 +0000
Message-ID: <16C12C4C-9E7C-4551-8D9F-0693E77D0DA2@netapp.com>
References: <7E50030C-4E5B-4185-9AA8-6AEE50BE1476@netapp.com> <6BF44A6D-215B-4F02-9E9A-74B00BC4DADE@ifi.uio.no>
In-Reply-To: <6BF44A6D-215B-4F02-9E9A-74B00BC4DADE@ifi.uio.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.106.53.51]
Content-Type: multipart/signed; boundary="Apple-Mail=_0FDBFB86-9E02-4238-95B1-D2D332020BFC"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Subject: Re: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jan 2014 12:53:50 -0000

--Apple-Mail=_0FDBFB86-9E02-4238-95B1-D2D332020BFC
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

On 2014-1-16, at 15:31, Michael Welzl  wrote:
> I vote for adoption.

Anyone else care to state an opinion?

Thanks,
Lars

--Apple-Mail=_0FDBFB86-9E02-4238-95B1-D2D332020BFC
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQCVAwUBUt5t29ZcnpRveo1xAQIIbgP/Qgn6XC1w+fOfY0plLj1C1Tsc1Xx7yTZr
17oXWqubftg8n+0u61gaRa6XiuCxShL/e7wDdC3RyoSQ3GF65ubnw5OWJQ5Y0p/J
+2zWftRlen6EbASlMTmY4tWWJshnhypV6tbzo9aSvn/zLiYyRFArSG6yhGPBsByg
aj2E5O2Vx2s=
=JSAh
-----END PGP SIGNATURE-----

--Apple-Mail=_0FDBFB86-9E02-4238-95B1-D2D332020BFC--

From ldecicco@gmail.com  Tue Jan 21 04:57:47 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63091A011A for ; Tue, 21 Jan 2014 04:57:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXa5XscVPQBO for ; Tue, 21 Jan 2014 04:57:46 -0800 (PST)
Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 223411A0115 for ; Tue, 21 Jan 2014 04:57:45 -0800 (PST)
Received: by mail-ob0-f171.google.com with SMTP id wp4so3499196obc.2 for ; Tue, 21 Jan 2014 04:57:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L9yBvRjiy0QPkflYpBgG6pitkDQAsP4fH/ylBlV63Zg=; b=opaTDfZJd6V2dICMPWxeVaJWk11aeBdMLuUs51twoJoJ+kP5w8U030y1I2ffQbAdKg S48J7ITA4FcbLU3ufiEDwSMjVT5kYWuXMddz5UcLeWqYtrNlCMVcEGjlfC379eNw+7w1 RxttftXB+aKef6lnm4yhvXA/440ZK9FHuVZfFwjqfZcjSccUTBA2r87NEt/9J/nVMsf2 0FOXDN66Js1ku1iBSQp722MvssCgeHHoxQsMQBF+u0K+pETp5A+7W3YzL51oDpN0/xM9 DkyVYmOnANt3C7BxphA0Chn39/AE1TS35cepIAENKYC6G6V/C34n0GbFN2LjsBZHCOkc Sdsg==
MIME-Version: 1.0
X-Received: by 10.182.22.135 with SMTP id d7mr20353080obf.1.1390309065870; Tue, 21 Jan 2014 04:57:45 -0800 (PST)
Received: by 10.76.2.78 with HTTP; Tue, 21 Jan 2014 04:57:45 -0800 (PST)
In-Reply-To: <16C12C4C-9E7C-4551-8D9F-0693E77D0DA2@netapp.com>
References: <7E50030C-4E5B-4185-9AA8-6AEE50BE1476@netapp.com> <6BF44A6D-215B-4F02-9E9A-74B00BC4DADE@ifi.uio.no> <16C12C4C-9E7C-4551-8D9F-0693E77D0DA2@netapp.com>
Date: Tue, 21 Jan 2014 13:57:45 +0100
Message-ID: 
From: Luca De Cicco 
To: "Eggert, Lars" 
Content-Type: multipart/alternative; boundary=001a11c2e190ffd1fd04f07a8d23
Cc: rmcat WG 
Subject: Re: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jan 2014 12:57:48 -0000

--001a11c2e190ffd1fd04f07a8d23
Content-Type: text/plain; charset=ISO-8859-1

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


On Tue, Jan 21, 2014 at 1:53 PM, Eggert, Lars  wrote:

> On 2014-1-16, at 15:31, Michael Welzl  wrote:
> > I vote for adoption.
>
> Anyone else care to state an opinion?
>
> Thanks,
> Lars
>

--001a11c2e190ffd1fd04f07a8d23
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I vote for the adoption.

Cheers,
<=
div>--
Luca De Cicco,=
 PhD, Eng.
Politecnico di Bari
Dipartimento di Elettrotecnica ed Elet=
tronica

Via Re David, 200 - Bari - ITALY
Office: +39 080 596 3851



On Tue, Jan 21, 2014 at 1:53 PM, Eggert,=
 Lars <lars@netapp.com> wrote:

On 2014-1-16, at 15:31, Michael Welzl <michawe@ifi.uio.no> wrote:

> I vote for adoption.



Anyone else care to state an opinion?



Thanks,

Lars





--001a11c2e190ffd1fd04f07a8d23--

From zaheduzzaman.sarker@ericsson.com  Tue Jan 21 05:34:46 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D45E1A00D3 for ; Tue, 21 Jan 2014 05:34:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCJ317wh7Uch for ; Tue, 21 Jan 2014 05:34:44 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 788091A00CC for ; Tue, 21 Jan 2014 05:34:42 -0800 (PST)
X-AuditID: c1b4fb30-b7faa8e000007034-45-52de776dcfcd
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id D3.F7.28724.D677ED25; Tue, 21 Jan 2014 14:34:39 +0100 (CET)
Received: from ESESSMB307.ericsson.se ([169.254.7.171]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0387.000; Tue, 21 Jan 2014 14:34:35 +0100
From: Zaheduzzaman Sarker 
To: "Eggert, Lars" , rmcat WG 
Thread-Topic: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
Thread-Index: AQHPEpYXwCGFx0stw0qE8XczVDv3zJqHWVYAgAfAYQCAABH9EA==
Date: Tue, 21 Jan 2014 13:34:34 +0000
Message-ID: 
References: <7E50030C-4E5B-4185-9AA8-6AEE50BE1476@netapp.com> <6BF44A6D-215B-4F02-9E9A-74B00BC4DADE@ifi.uio.no> <16C12C4C-9E7C-4551-8D9F-0693E77D0DA2@netapp.com>
In-Reply-To: <16C12C4C-9E7C-4551-8D9F-0693E77D0DA2@netapp.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+JvjW5B+b0gg+NvuS1evO5hsVh98wOb A5PHkiU/mTxmfPrCFsAUxWWTkpqTWZZapG+XwJXx8ss2poLzPBW/j69mbGC8wdXFyMkhIWAi 8XnTSRYIW0ziwr31bF2MXBxCAocYJe4ePgTlLGGUOHnzI1MXIwcHm4CNxOPFfiANIgL2EndW HmIHsYUF7CQObV3BDBM/13wLrFxEwEni+Cd9kDCLgKrE9DlzwMp5BXwlXm46xAoxfinQ+Gv/ wXo5gebsf/iCEcRmBDro+6k1TCA2s4C4xK0n85kgDhWQWLLnPDOELSrx8vE/VpBdEgKKEsv7 5SDK9SRuTJ3CBmFrSyxb+JoZYq+gxMmZT1gmMIrOQjJ1FpKWWUhaZiFpWcDIsoqRPTcxMye9 3HwTIzASDm75bbCDcdN9sUOM0hwsSuK8H946BwkJpCeWpGanphakFsUXleakFh9iZOLglGpg 9DzJ6vgwtjHeOv10rPc/KyUrUb2Sg3fVVk2eWrj8vEZVzGT1k7vFBcPOLa6f+IFbnXP5vQ+T mWqa/z2wl247cbyss2Z+jXvqndgTnvFdQV0cHwXflW04tCnhfNuZtIY10Q+/Or/s+Lbt9r9X Yl2TgvJf6yw88V516QvTMoHdqorV7jkXfGZsUmIpzkg01GIuKk4EAOhXWFZSAgAA
Subject: Re: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jan 2014 13:34:46 -0000

Hi,

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

Will there be separation in the next version of this draft and we adopt bot=
h of them? What is the possibility that the current eval draft is adopted a=
s it is then separate it later?

BR

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=
=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
Multimedia Technologies

Ericsson
Laboratoriegr=E4nd 11
97128 Lule=E5, Sweden
Phone +46 10 717 37 43
Mobile +46 76 115 37 43
Office +46 76 115 37 43
Fax +46 920 996 21
zaheduzzaman.sarker@ericsson.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=
=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


> -----Original Message-----
> From: rmcat [mailto:rmcat-bounces@ietf.org] On Behalf Of Eggert, Lars
> Sent: den 21 januari 2014 13:54
> To: rmcat WG
> Subject: Re: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
> Importance: High
>=20
> On 2014-1-16, at 15:31, Michael Welzl  wrote:
> > I vote for adoption.
>=20
> Anyone else care to state an opinion?
>=20
> Thanks,
> Lars

From lars@netapp.com  Tue Jan 21 05:49:12 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F10E1A0113 for ; Tue, 21 Jan 2014 05:49:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.437
X-Spam-Level: 
X-Spam-Status: No, score=-7.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAM8n2jip3U3 for ; Tue, 21 Jan 2014 05:49:11 -0800 (PST)
Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 518871A00B8 for ; Tue, 21 Jan 2014 05:49:11 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.95,696,1384329600";  d="asc'?scan'208";a="138166881"
Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx12-out.netapp.com with ESMTP; 21 Jan 2014 05:49:11 -0800
Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 05:49:10 -0800
From: "Eggert, Lars" 
To: Zaheduzzaman Sarker 
Thread-Topic: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
Thread-Index: AQHPEpYXwCGFx0stw0qE8XczVDv3zJqH8DYAgAfAX4CAAAtlAIAABBGA
Date: Tue, 21 Jan 2014 13:49:10 +0000
Message-ID: <711CAF57-DF3B-442D-8D7A-4EA3CA8EBF46@netapp.com>
References: <7E50030C-4E5B-4185-9AA8-6AEE50BE1476@netapp.com> <6BF44A6D-215B-4F02-9E9A-74B00BC4DADE@ifi.uio.no> <16C12C4C-9E7C-4551-8D9F-0693E77D0DA2@netapp.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.106.53.51]
Content-Type: multipart/signed; boundary="Apple-Mail=_D91589D1-DF39-4690-B403-B1A438984D37"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Cc: rmcat WG 
Subject: Re: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jan 2014 13:49:12 -0000

--Apple-Mail=_D91589D1-DF39-4690-B403-B1A438984D37
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Hi,

On 2014-1-21, at 14:34, Zaheduzzaman Sarker =
 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.=20
>=20
> 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?

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

--Apple-Mail=_D91589D1-DF39-4690-B403-B1A438984D37
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQCVAwUBUt5609ZcnpRveo1xAQI3FQP/Zc/wRt6AY9qTfwSg+KvM5MfRXpeyyecm
/C04ERzMHy3Tns5yua7nsNM39a5u/4Ytv7eLzT8yFu3E+E1syzjegbObXkxcZghJ
HnPErlLbzkeSjsTlrBKvwa/9NIsMAmM4SGm5lCJXxkWvA8oeH/zNKG/XQtv2JOUo
LtgKyQX14IY=
=wRKw
-----END PGP SIGNATURE-----

--Apple-Mail=_D91589D1-DF39-4690-B403-B1A438984D37--

From saverio.mascolo@gmail.com  Tue Jan 21 07:54:11 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBDC1A037E for ; Tue, 21 Jan 2014 07:54:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJZ1rNc2AqY3 for ; Tue, 21 Jan 2014 07:54:08 -0800 (PST)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id EEEAF1A036E for ; Tue, 21 Jan 2014 07:54:07 -0800 (PST)
Received: by mail-wg0-f41.google.com with SMTP id n12so5119715wgh.2 for ; Tue, 21 Jan 2014 07:54:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=q8vY6XURR+TauvmWLU8AtNMCNatsR6OERs0aM0juQFM=; b=kYIgANLotUs4oCswJgbOz0b1cmms3ZmtN0y0YoE5bYOtXZq6jA9FupNiFfcYu/4H5N B0F6fOJ05hykMMAfNYUOH4u8USrNHWFpdP5sFU9DaIcnBP7e2ex4PZYEFdWlfpwJT+Ae RNX3P3NyA8+eV9+mczfqvL8+UvQ4nkuuxNH60qVSoT9Vjm2fBmHTKJDTH2lQj45Wq9SE K1SU/17YoZJ0Q0dKi2qXspL4oLSrLz2sRatd0JsopbncoentSdV0TAkSrWO4P1+VttAz QZdKzXXgS+gn8z5stLhvpnW0zcrb2WINkE1D/0QCwd+UBxsaoQ5jPXM3ojSbEV312Y7x IZ0Q==
X-Received: by 10.180.218.171 with SMTP id ph11mr14976480wic.7.1390319647233;  Tue, 21 Jan 2014 07:54:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.227.133.9 with HTTP; Tue, 21 Jan 2014 07:53:47 -0800 (PST)
In-Reply-To: <7E50030C-4E5B-4185-9AA8-6AEE50BE1476@netapp.com>
References: <7E50030C-4E5B-4185-9AA8-6AEE50BE1476@netapp.com>
From: Saverio Mascolo 
Date: Tue, 21 Jan 2014 16:53:47 +0100
Message-ID: 
To: "Eggert, Lars" 
Content-Type: multipart/alternative; boundary=001a1134d230b29c8104f07d04d1
Cc: rmcat WG 
Subject: Re: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jan 2014 15:54:11 -0000

--001a1134d230b29c8104f07d04d1
Content-Type: text/plain; charset=ISO-8859-1

I vote for the adoption

saverio mascolo


On Thu, Jan 16, 2014 at 9:36 AM, Eggert, Lars  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:mascolo@poliba.it

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.

--001a1134d230b29c8104f07d04d1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I vote for the adoption

saverio mascolo
=



O=
n Thu, Jan 16, 2014 at 9:36 AM, Eggert, Lars <lars@netapp.com> wrote:



Hi,



in March 2013, I asked if we're ready to adopt draft-singh-rmcat-cc-eva=
l 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 are=
a is going.





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





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



Lars





-- Saverio Mascolo, Full Professor
Dipartimento di Elettrotecnica ed Elet=
tronica
Politecnico di Bari
Via Orabona 4, 70125 Bari Italy
Tel. +=
39 080 5963621


Fax. +39 080 5963410
email:mascolo@poliba.it
=A0
http://c3lab.poliba.it


=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


=A0This message may contain confidential and/or legally privileged informat=
ion.
=A0 If you are not the intended recipient of the message, please de=
stroy it.
=A0Any unauthorized dissemination, distribution, or copying of=
 the material in


=A0this message, and any attachments to the message, is strictly forbidden.



--001a1134d230b29c8104f07d04d1--

From wes@mti-systems.com  Tue Jan 21 14:22:42 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032A11A024C for ; Tue, 21 Jan 2014 14:22:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfiRtyq0NqSB for ; Tue, 21 Jan 2014 14:22:40 -0800 (PST)
Received: from atl4mhob06.myregisteredsite.com (atl4mhob06.myregisteredsite.com [209.17.115.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4F01A0248 for ; Tue, 21 Jan 2014 14:22:40 -0800 (PST)
Received: from mailpod.hostingplatform.com ([10.30.71.205]) by atl4mhob06.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s0LMMc97028495 for ; Tue, 21 Jan 2014 17:22:38 -0500
Received: (qmail 27277 invoked by uid 0); 21 Jan 2014 22:22:38 -0000
X-TCPREMOTEIP: 107.48.65.41
X-Authenticated-UID: wes@mti-systems.com
Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.48.65.41) by 0 with ESMTPA; 21 Jan 2014 22:22:34 -0000
Message-ID: <52DEF308.7010308@mti-systems.com>
Date: Tue, 21 Jan 2014 17:22:00 -0500
From: Wesley Eddy 
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Eggert, Lars" , rmcat WG 
References: <7E50030C-4E5B-4185-9AA8-6AEE50BE1476@netapp.com> <6BF44A6D-215B-4F02-9E9A-74B00BC4DADE@ifi.uio.no> <16C12C4C-9E7C-4551-8D9F-0693E77D0DA2@netapp.com>
In-Reply-To: <16C12C4C-9E7C-4551-8D9F-0693E77D0DA2@netapp.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jan 2014 22:22:42 -0000

On 1/21/2014 7:53 AM, Eggert, Lars wrote:
> On 2014-1-16, at 15:31, Michael Welzl  wrote:
>> I vote for adoption.
> 
> 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 geertv@qti.qualcomm.com  Tue Jan 21 16:50:09 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60551A0266 for ; Tue, 21 Jan 2014 16:50:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.536
X-Spam-Level: 
X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUj9cJ-dioqa for ; Tue, 21 Jan 2014 16:50:06 -0800 (PST)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 52EB71A024F for ; Tue, 21 Jan 2014 16:50:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1390351806; x=1421887806; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=q7Sff519l2KVcBMkaralEkfbGLzI1cCXh4007MDS1F0=; b=e89vEX+Uxe7KTSKYVRFND154dlp6OhvZStYkGI2qTpKu+bYA09QXX0Fb x0NLIO0f6vKmdS1Wyt0OQiCpKY2g1DwbkOmbS4feYnPgRin6tgC5jafJY lrs/epKGVb4nip84bMS1OOMr22m2/2KjyDKavDv2yFx+PKZGS1B4soIf6 0=;
X-IronPort-AV: E=McAfee;i="5400,1158,7325"; a="58472654"
Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 21 Jan 2014 16:50:06 -0800
X-IronPort-AV: E=McAfee;i="5400,1158,7325"; a="26094009"
Received: from nasanexhc12.na.qualcomm.com ([172.30.39.187]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 21 Jan 2014 16:50:05 -0800
Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc12.na.qualcomm.com (172.30.39.187) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 21 Jan 2014 16:50:05 -0800
Received: from NASANEXD02B.na.qualcomm.com ([169.254.2.35]) by nasanexhc05.na.qualcomm.com ([172.30.48.2]) with mapi id 14.03.0158.001; Tue, 21 Jan 2014 16:50:05 -0800
From: "Van Der Auwera, Geert" 
To: rmcat WG 
Thread-Topic: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
Thread-Index: AQHPEpYXwCGFx0stw0qE8XczVDv3zJqH8DYAgAfAX4CAAAtlAIAANLZA
Date: Wed, 22 Jan 2014 00:50:04 +0000
Message-ID: <4FC1F85139E6FE4D9A55BD6798B29A482687BB17@NASANEXD02B.na.qualcomm.com>
References: <7E50030C-4E5B-4185-9AA8-6AEE50BE1476@netapp.com> <6BF44A6D-215B-4F02-9E9A-74B00BC4DADE@ifi.uio.no> <16C12C4C-9E7C-4551-8D9F-0693E77D0DA2@netapp.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.30.48.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Eggert, Lars" 
Subject: Re: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jan 2014 00:50:09 -0000

Hi,

I am also in favor of adoption.

Best regards,

Geert Van der Auwera


-----Original Message-----
From: rmcat [mailto:rmcat-bounces@ietf.org] On Behalf Of Zaheduzzaman Sarke=
r
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,

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

Will there be separation in the next version of this draft and we adopt bot=
h of them? What is the possibility that the current eval draft is adopted a=
s it is then separate it later?

BR

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=
=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
Multimedia Technologies

Ericsson
Laboratoriegr=E4nd 11
97128 Lule=E5, Sweden
Phone +46 10 717 37 43
Mobile +46 76 115 37 43
Office +46 76 115 37 43
Fax +46 920 996 21
zaheduzzaman.sarker@ericsson.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=
=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


> -----Original Message-----
> From: rmcat [mailto:rmcat-bounces@ietf.org] On Behalf Of Eggert, Lars
> Sent: den 21 januari 2014 13:54
> To: rmcat WG
> Subject: Re: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
> Importance: High
>=20
> On 2014-1-16, at 15:31, Michael Welzl  wrote:
> > I vote for adoption.
>=20
> Anyone else care to state an opinion?
>=20
> Thanks,
> Lars

From lars@netapp.com  Wed Jan 22 02:30:49 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 164EC1A01EB for ; Wed, 22 Jan 2014 02:30:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.437
X-Spam-Level: 
X-Spam-Status: No, score=-7.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vo6A3qHibX1L for ; Wed, 22 Jan 2014 02:30:47 -0800 (PST)
Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id ACF021A02C0 for ; Wed, 22 Jan 2014 02:30:47 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.95,698,1384329600";  d="asc'?scan'208";a="303544489"
Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx1-out.netapp.com with ESMTP; 22 Jan 2014 02:30:47 -0800
Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Wed, 22 Jan 2014 02:30:47 -0800
From: "Eggert, Lars" 
To: rmcat WG 
Thread-Topic: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
Thread-Index: AQHPEpYXwCGFx0stw0qE8XczVDv3zJqH8DYAgAfAX4CAAAtlAIAANLZAgAEqQAA=
Date: Wed, 22 Jan 2014 10:30:45 +0000
Message-ID: <2B3C5ACA-0A5F-40D8-AD89-08441C655671@netapp.com>
References: <7E50030C-4E5B-4185-9AA8-6AEE50BE1476@netapp.com> <6BF44A6D-215B-4F02-9E9A-74B00BC4DADE@ifi.uio.no> <16C12C4C-9E7C-4551-8D9F-0693E77D0DA2@netapp.com>  <4FC1F85139E6FE4D9A55BD6798B29A482687BB17@NASANEXD02B.na.qualcomm.com>
In-Reply-To: <4FC1F85139E6FE4D9A55BD6798B29A482687BB17@NASANEXD02B.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.106.53.51]
Content-Type: multipart/signed; boundary="Apple-Mail=_4C54AB01-B910-416D-B7DC-93A5EC6A6A1A"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Subject: Re: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jan 2014 10:30:49 -0000

--Apple-Mail=_4C54AB01-B910-416D-B7DC-93A5EC6A6A1A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

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

Lars

--Apple-Mail=_4C54AB01-B910-416D-B7DC-93A5EC6A6A1A
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQCVAwUBUt+d0tZcnpRveo1xAQIfoQQAj7aFyHMhcLQUkV4YFqchAJiGFI6NCtMt
kkZswG9REvFC62Wjfl84R2AVFlJFkzQ7Q5as+Z7/V4BBcDECfnplDsqsAvwZtFYi
tQXYaA+7YOUFSWzB1vq3Alr79BgANrvRBx5hd7jY7EslcJbe+dCoUHmGU+P6V5Yh
aKT5Eh6L8tA=
=qNum
-----END PGP SIGNATURE-----

--Apple-Mail=_4C54AB01-B910-416D-B7DC-93A5EC6A6A1A--

From randell-ietf@jesup.org  Wed Jan 22 10:56:50 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFAD1A0154 for ; Wed, 22 Jan 2014 10:56:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.997
X-Spam-Level: ***
X-Spam-Status: No, score=3.997 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FRT_STOCK2=3.988, RCVD_IN_DNSWL_NONE=-0.0001, T_FRT_STOCK2=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ow8pITA63ext for ; Wed, 22 Jan 2014 10:56:47 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id BF0A91A011D for ; Wed, 22 Jan 2014 10:56:47 -0800 (PST)
Received: from pool-173-49-144-199.phlapa.fios.verizon.net ([173.49.144.199]:3011 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1W62yj-0009v3-NZ for rmcat@ietf.org; Wed, 22 Jan 2014 12:56:47 -0600
Message-ID: <52E0141F.4060805@jesup.org>
Date: Wed, 22 Jan 2014 13:55:27 -0500
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: rmcat@ietf.org
References:  <52C17E9F.8060703@alvestrand.no>  <52C60213.9000401@alvestrand.no>  
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org
Subject: Re: [rmcat] 5 tuples and rmcat-cc-requirements-01
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jan 2014 18:56:50 -0000

I'm going to make deeper comments once I read through everything, but 
some detail points while I have them in front of me:

One big issue for bundle is that ICE takes time, and it takes time 
proportional to the number of ports you have to open.  From experience, 
the more ports needing to be opened the more probably you can get.  For 
Hangout-like conferencing, "classic" RTP setup would mean 5 + 4(n-1) 
ports where N is the number of participants at least, or more likely 7 + 
6(n-1) (assuming we do simulcast and do it on a separate RTP/RTCP 
stream).  It also means 4 or 6 times the amount of TURN ports needed by 
a service offering WebRTC. (One day, ICE and TURN will die the horrible 
death they should when IPV6 is the norm - but even then it may be needed 
for things like firewalls that block UDP.)

This drives a) RTP/RTCP mux (already being done, and predates WebRTC), 
and BUNDLE.  With both, you can get 2 or 1 ports for a conference 
(depending on if you bundle the DataChannel flow).

On 1/3/2014 11:18 PM, Dave Taht wrote:
> On Fri, Jan 3, 2014 at 3:25 AM, Michael Welzl  wrote:
>> [snip]
>>
>> My gut tells me you want one tuple per voice and per video flow, AND
>> to manage their congestion indicators together, but depending on the
>> level of statistical multiplexing of the video flows they could go on
>> a single tuple.
>>
>>
>> That looks approximately sensible to me too.
>>
>>
>> Not so much to me. Dave's gut seems to argue for separate treatment of audio
>> and video in the network - what for? To protect them from each other,
>> because the sending application doesn't know what it's doing?
> 0) audio behaves way differently than video, and should be differentiated.
> I personally care not a whit if my video goes to hell once in a while. I care
> a lot if my audio does. Videoconferences do contain a lot of visual information
> but audio, despite being truly tiny relatively, is critical.

Audio is critical in a conference, true.  However when we're constrained 
for bandwidth we may want to reduce audio bandwidth targets rather than 
drop video totally or have sucky video - especially if we're running 
higher-than-current-quality audio (Opus and WebRTC (will) support 
multi-channel audio at virtually lossless levels - but that takes a lot 
more bandwidth than current default audio settings).

Also, perceptually a conversation over video feels "real" when the video 
is high frame rate (>20 consistently, pref 30 rock solid). letting it 
occasionally get nuked (or even drop frame rate noticably) takes you out 
of that mode of perception.

The relative priority of these things is something that feeds back to 
the application needs, which will vary.

> 1) To differentiate them from other flows on the network. The sending
> application
> can't know what those flows are doing.
>
> 2) To make analysis easier from tools like wireshark (my immediate need).
> What my gut says and what experiment shows is often very different. I
> can see some problems with splitting tuples like this, like adding an
> extra system call every 10ms or so, and having to explicitly be aware of
> joint time stamps from two streams, but I think they are small problems
> relative to the potential benefits.

Wireshark can separate flows on the same tuple using SSRC & payloads.  
There's an issue for Wireshark in that the payloads and signaling are 
all encrypted/hidden/application-specific - oh well. Same applies to 
encrypted SIP calls.  The only addition is SSRC muxing onto one 5-tuple, 
which wireshark can understand if it wants.  It can if it likes infer 
audio or video from the payload and size (and Mark), of course it can be 
wrong.

> 3) To take advantage, where possible, of different scheduling and classification
> techniques in the network. A strict drop tail or AQM system won't be
> affected by adding in this support, although I foresee better mixing on the
> endpoints as being a benefit across any network technology. I'd like
> to be fiddling with ECN as well.
>
> What I think I see now is enormous bursts of video and audio on periods
> far greater than 10ms in the data I have, with bad collapses, bursty packet
> loss, and lousy recovery time. So I'm poking at sources...

Typical audio is close to isochronous at 20ms.  Video will be bursts 
(perhaps metered onto the wire) every 33-100ms or so.  Below ~300K it 
will be 1-packet bursts typically.  Note: this gets messier with the 
default behavior in current WebRTC to use retransmission on loss reports 
if the RTT is low enough.  I have issues with this behavior for recovery 
of video; typically I prefer a dynamic refresh using a pframe against an 
older reference frame (or other non-iframe/IDR recovery method).  It 
avoids making congestion problems causing loss worse...  I know Justin 
Uberti (of Google) strongly prefers to use retransmission based on their 
experience with Hangouts (which (were) using H.264 SVC).  They also may 
be able to put servers closer to users that can short-circuit 
retransmissions without going all the way back to the source (in a 
conference).

> Wifi uses 4 levels of classification in 802.11e which in linux at 
> least is mapped to CS0 through CS7. 

WiFi is a whole other headache.... and an important one.

>> to get audio through with near zero loss - but I don't want to embed that
> I'd like to see it get through with near zero jitter, delay, and loss in
> roughly that order. non-bursty loss is easily compensated for.

Audio single-packet loss concealment is pretty good in Opus (and iLBC, 
and I believe in iSAC).  Ok to so-so in other codecs.  And single-packet 
losses are easy enough to hide that generally the experience will be 
better allowing a moderate amount of them INSTEAD of video losses.  Odd, 
but true.

I'll note that video being delayed behind audio is NOT a good thing; 
it's actually bad.  The reason is lip-sync.  Humans hate seeing video 
that lags audio - they're somewhat used to audio lagging video (see 
something in the distance, then hear it), but not tolerant of the 
reverse.  So if video is delayed, we have to artificially delay audio to 
match (run deeper jitter buffers than needed, basically). If you're 
doing non-realtime streaming, it's not an issue, but for realtime the 
delay for playback is the *worst* of the synchronized sub-streams.

Video is rather more tolerant of loss -- skipped frames aren't 
super-noticable, and often a lost packet doesn't cause major artifacts 
(if you do decode-with-errors-until-recovery instead of 
freeze-until-recovery, which gives much longer freezes but no errors, or 
freeze-until-retransmit which can lead to video high-speed "catchup" 
when the lost packet gets through, which is kinda odd).

>> assumption into the application; I'd much prefer that the application could
>> make an explicit decision on what's important to it, and that ways be found
>> to let the network respect that wish.
> I would like something of the inverse, I'd like the presence of packet
> scheduling to
> be detected by the application and utilized if seen, by correlating the
> differences in behavior between a high rate and a low rate flow in particular.

Different applications have different needs on the streams.  Some may 
want to drop a stream rather than get by with less bits for other 
streams, or drop video rather than degrade both it and audio, or drop 
secondary video channels to keep the primary happy.  A VRS service may 
put video (and consistent frame rate!) above audio in importance.

> I'm also very interested in determining the effects of the leading
> AQM and packet scheduling candidates on videoconferencing in general.

Absolutely!  and please reach out to me again; our attempts to get a 
call in before xmas got lost in the busy period that led to Mozilla's 
holiday shutdown (and some personal issues).

>
> At the moment, however, what I'd mostly like is the ability to experiment.
> Building chromium has thus far been no fun, although I think great strides
> could be made with only a few dozen lines of added code.

It's much easier to build Firefox.... ;-)  Though it can still take some 
time.  Install mercurial, clone mozilla-central (our trunk), install 
some dependencies if needed (generally not needed), and "./mach build".  
There are more things you can do, but that's the basics.

>> +1.
>> Separating tuples can help to let the network protect a flow against *any*
>> other flow, but for prioritization between flows coming from the same
>> application, you should be much better off with joint congestion management,
>> where you have 100% control over priorities and get other benefits too. My
>> argument is: "send stuff into the network the right way rather than hoping
>> for the network to correct your mistakes."
> I think it is best to do both.
>
> I think it is incorrect to use the word prioritization when it comes
> to the effects of packet scheduling. When I think of prioritization
> I think of using diffserv or dpi to classify packets into bins. When
> I think of scheduling, fair queuing, flow queueing, etc.,
> I think of identifying flows and doing better mixing between them;
> of turning packets back into packets again.
>
> Certainly, folk are discovering that sending large bursts into the
> network is a bad idea. See for example the recent "Bullet Train"
> paper.
>
> http://conferences.sigcomm.org/co-next/2013/program/p133.pdf

This is a scale of bursts way beyond anything in a WebRTC application 
(even video streaming, which they mention, is 64KB-2MB per burst).  A 
"very large" burst for WebRTC would be maybe 10-20KB; rarely would it 
get to that level except at super-high bitrates (and then rarely).  So 
nothing much from this is applicable (at a quick reading).

>
> Although I feel adding AQM and packet scheduling are necessary for
> the current and next generation of nearly all network technologies,
> I am tracking improvements in how we do server and client side
> stuff closely also.
>
> An endpoint result of all the back and forth about aqm, packet scheduling,
> burstyness, and bufferbloat over the last 3 years has been huge reductions in
> buffering across the linux stack, a switch to a more pull
> model for tcp in particular gradually between linux 3.3 and 3.12,
> and the recent addition of a paced fq packet scheduler in 3.12
> which is yielding quite excellent results for tcp and video
> streams thus far.
>
> http://thread.gmane.org/gmane.linux.network/281023

a) 90% of our traffic in WebRTC is Windows.  b) most of the rest is 
Mac.  c) that's TCP traffic with an "infinite" source it appears; we 
have paced senders.  Even when we use TURN-TCP we'll have a (regular) 
bursty flow with idle times.

Not to say that isn't good - it's good!  and it also makes other 
realtime things competing with TCP much, much happier.

> I think it is probable that this will evolve to become a default qdisc
> for linux in general, and that applications should be
> twidding with the pacing value in order to get good results
> out of the OS on granularities lower than 10ms.
>
> (does anyone know the new setsockopt for this?)
>
> That said, certain kinds of layer 2 technologies (wifi, cable,
> 3g) *require* bursts in order to function at their highest bandwidth,
> and we've trimmed so much fat from Linux in particular that
> we're at having to fix device drivers and devices again:
>
> http://www.spinics.net/lists/stable-commits/msg30001.html
>
> So yes, I strongly support good mixing from the application level
> and for it to be as self aware as possible of its total impact on the
> network.
>
> But: although web browsers are complex and for many users
> their entire OS (sigh), there is not enough information about
> the hosts's other applications, the network and all the devices
> held there to do all the job, thus giving the network more
> information about flows in general is a good idea.

Agreed.  But it's not all simple...

> And I also strongly encourage experimentation with this stuff.
> Me being me, I designed a bunch of experiments, emulated
> every technology I could (DSL, cable, wifi, ethernet),
> got a lot of data, started looking at captures long before
> I started looking at source code and started raising questions
> here on rmcat. I figure that's backwards from how most
> people operate.

:-)

>> Which may lead us back very close to the guidelines that were enshrined in
>> RTP and SDP specifications 20 years ago .... but then again, it might not.
> Cite? I still dimly remember an internet that ran on more ports than 53, 22,
> 80 and 443. I remember when sip ran on a specific port and RTP was
> constrained to a specific port range. The fomer seemed a good idea,
> the latter didn't work out so well in the post-nat era.

RTP was never constrained that I know of; many applications limited RTP 
to things like >16384 for no real apparent reason other than maybe to 
make it easier to write router/NAT/firewall rules.  :-)

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


From randell-ietf@jesup.org  Wed Jan 22 11:23:47 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886311A03E6 for ; Wed, 22 Jan 2014 11:23:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSzOLlwJi2eB for ; Wed, 22 Jan 2014 11:23:45 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 568321A03D1 for ; Wed, 22 Jan 2014 11:23:45 -0800 (PST)
Received: from pool-173-49-144-199.phlapa.fios.verizon.net ([173.49.144.199]:3076 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1W63Oq-0005AC-8V for rmcat@ietf.org; Wed, 22 Jan 2014 13:23:44 -0600
Message-ID: <52E01A75.30007@jesup.org>
Date: Wed, 22 Jan 2014 14:22:29 -0500
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: rmcat@ietf.org
References:  <52C17E9F.8060703@alvestrand.no>  <52C60213.9000401@alvestrand.no>   <07E05385-225C-4CD9-868C-E86992447BDD@ifi.uio.no> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-4.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org
Subject: Re: [rmcat] 5 tuples and rmcat-cc-requirements-01
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jan 2014 19:23:47 -0000

On 1/4/2014 3:54 PM, Dave Taht wrote:
> On Sat, Jan 4, 2014 at 5:28 AM, Michael Welzl  wrote:
>
>> Personally, I would be cautious about drawing conclusions from experiments with things that we know to be moving targets. For example, I can't see that you would be able to get an answer to the questions we're discussing here from experimenting with Chromium today.
> I long ago drew a conclusion that current networks have way too much
> buffering for any form of congestion control we know of to work right
> for videoconferencing vs deployed tcps on cable, wifi, 3g and LTE.
> Some hope on DSL & gpon. DSL because most that I have tried already
> have some form of aqm or packet scheduling, gpon as it seems pretty
> good on uploads, and not horrible on downloads.

No realtime flow in the current environment (buffering, greedy TCP) can 
do really well; see the papers and notes from the IAB Realtime 
Congestion Control Workshop that occurred with the BOF for RMCAT 
(Vancouver a year and a half ago).  TCP will try to eat your lunch 
eventually unless someone separates it out (even if there's no 
buffering), unless you're nasty and refuse.  In droptail/etc esp. with 
bloat, this is Bad, as TCP will put you in a queue.  With AQM, you may 
lose but the queuing won't be bad, and you'll see loss you can react 
to.  (And note that current experiments likely haven't tuned the loss 
behavior for AQM yet, though the requirements say they'll need to.)

>
> As for experimentation, certainly answers can be obtained from the
> moving targets!

Just be careful to remember the moving targets may not be stable or 
indicative of the behavior envisioned by the requirements.

>
> Chromium is open source, so anybody can hack on it. I got a build done
> last night. Adding in the bits of code and packet handling I'm
> discussing experimenting with is fairly trivial. (finding where to add
> it and working through the overlarge set of c++ abstractions is thus
> far proving difficult.)
>
> I am interested in the following experiments:
>
> finding the "right" rate quickly

A known flaw in Google's algorithm currently.  My old algorithm 
(Worlgate/Ojo) was very aggressive at the start of a flow and would 
overshoot, then notice queuing developing and back off fast to drain.  
After ~30 seconds it got more conservative about putting it's toes over 
the apparent available bandwidth (high water); when recovering from 
local dips it would be moderately aggressive up to the high-water-mark 
for a stable flow with no delay buildup. Startup behavior was discussed 
a lot 2 years ago on rtcweb.  Also, people who do HD conferences on 
high-bandwidth links and local LANs really, really want to start much 
higher (and adapt up faster).

> dealing with non-congestive (e.g. wifi) losses

Yup.  I used to allow a small amount of loss, then apply modifiers on 
top of apparent delay over a loss threshold (progressively).  You 
generally don't know the cause of a loss (especially in AQM).

> improving recovery after a congestive loss
> better analysis via rtp on separate tuples
> looking at the effects of various proposed classification schemes, and
> how to detect if they are preserved end to end
> what ecn could be used for (and testing for end to end preservation also)
> looking at the interactions of what network types exist today
> (dsl,cable, wifi, 3g) in general

Yup, all interesting.

> looking at aqm and packet scheduling vs drop tail behaviors.

Absolutely and called for in the requirements and the testing doc from 
Varun.

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


From randell-ietf@jesup.org  Wed Jan 22 11:29:18 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86001A02D5 for ; Wed, 22 Jan 2014 11:29:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzdbCqpdZAUR for ; Wed, 22 Jan 2014 11:29:17 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5F81A03FB for ; Wed, 22 Jan 2014 11:29:16 -0800 (PST)
Received: from pool-173-49-144-199.phlapa.fios.verizon.net ([173.49.144.199]:3089 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1W63UA-0007OZ-Ut for rmcat@ietf.org; Wed, 22 Jan 2014 13:29:15 -0600
Message-ID: <52E01BC0.1030700@jesup.org>
Date: Wed, 22 Jan 2014 14:28:00 -0500
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: rmcat@ietf.org
References: <7E50030C-4E5B-4185-9AA8-6AEE50BE1476@netapp.com> <6BF44A6D-215B-4F02-9E9A-74B00BC4DADE@ifi.uio.no> <16C12C4C-9E7C-4551-8D9F-0693E77D0DA2@netapp.com>  <4FC1F85139E6FE4D9A55BD6798B29A482687BB17@NASANEXD02B.na.qualcomm.com> <2B3C5ACA-0A5F-40D8-AD89-08441C655671@netapp.com>
In-Reply-To: <2B3C5ACA-0A5F-40D8-AD89-08441C655671@netapp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-4.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org
Subject: Re: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jan 2014 19:29:19 -0000

I'm in favor of adoption

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


From mzanaty@cisco.com  Thu Jan 23 08:34:12 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0071E1A005D for ; Thu, 23 Jan 2014 08:34:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.036
X-Spam-Level: 
X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XI4zTFJdatms for ; Thu, 23 Jan 2014 08:34:10 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDA21A0056 for ; Thu, 23 Jan 2014 08:34:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=67; q=dns/txt; s=iport; t=1390494850; x=1391704450; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=V6T4UDJ8pY0BcA+4Kz11HizMW7XnaaOR7dj+UiZPEnk=; b=VD90zQwjS7A7iikrRd8kfIfUTbfY7Y2bhNLb0V3GmgReY4IbKC7M0NOj UeDc80EPDztblF0QQ07HYf4E9o1BWG2LFuwPaCSuTeJysQYIiwbM5Yu8/ YiVkfvmJnZW/XJg8HlgrT61S8BvlYHUxG3g89SpMkp/S7Xhnk+KrDg58Y k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFAEJD4VKtJXG9/2dsb2JhbABbgwyBDrt1gRAWdIImAQEEOk8CAQg2EDIlAgSIGMV7F48HhDgEmCOSGIMtgio
X-IronPort-AV: E=Sophos;i="4.95,706,1384300800"; d="scan'208";a="299244669"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 23 Jan 2014 16:34:09 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0NGY9UT012665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 23 Jan 2014 16:34:09 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.19]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Thu, 23 Jan 2014 10:34:09 -0600
From: "Mo Zanaty (mzanaty)" 
To: "rmcat@ietf.org" 
Thread-Topic: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
Thread-Index: AQHPGFjw3HhgHwrWy0CY7sIR81inVg==
Date: Thu, 23 Jan 2014 16:34:08 +0000
Message-ID: 
References: <7E50030C-4E5B-4185-9AA8-6AEE50BE1476@netapp.com> <6BF44A6D-215B-4F02-9E9A-74B00BC4DADE@ifi.uio.no> <16C12C4C-9E7C-4551-8D9F-0693E77D0DA2@netapp.com>  <4FC1F85139E6FE4D9A55BD6798B29A482687BB17@NASANEXD02B.na.qualcomm.com> <2B3C5ACA-0A5F-40D8-AD89-08441C655671@netapp.com> <52E01BC0.1030700@jesup.org>
In-Reply-To: <52E01BC0.1030700@jesup.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.81.3.36]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <23685F482AF25945A94D4BCECF42CA20@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jan 2014 16:34:12 -0000

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

Mo


From randell-ietf@jesup.org  Fri Jan 24 08:09:04 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B851A04D1 for ; Fri, 24 Jan 2014 08:09:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AL4y99znghcQ for ; Fri, 24 Jan 2014 08:09:02 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id DBE4B1A04CD for ; Fri, 24 Jan 2014 08:09:02 -0800 (PST)
Received: from pool-173-49-144-199.phlapa.fios.verizon.net ([173.49.144.199]:1989 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1W6jJV-0009Nt-7s for rmcat@ietf.org; Fri, 24 Jan 2014 10:09:01 -0600
Message-ID: <52E2900A.5040804@jesup.org>
Date: Fri, 24 Jan 2014 11:08:42 -0500
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: rmcat@ietf.org
References:  <52C17E9F.8060703@alvestrand.no>  <52C60213.9000401@alvestrand.no>   <52E0141F.4060805@jesup.org>
In-Reply-To: <52E0141F.4060805@jesup.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Authenticated-Sender: randell@jesup.org
X-OutGoing-Spam-Status: No, score=-6.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org
Subject: Re: [rmcat] 5 tuples and rmcat-cc-requirements-01
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 16:09:04 -0000

On 1/22/2014 1:55 PM, Randell Jesup wrote:
> I'm going to make deeper comments once I read through everything, but 
> some detail points while I have them in front of me:
>
> One big issue for bundle is that ICE takes time, and it takes time 
> proportional to the number of ports you have to open.  From 
> experience, the more ports needing to be opened the more probably you 
> can get.  For Hangout-like conferencing, "classic" RTP setup would 
> mean 5 + 4(n-1) ports where N is the number of participants at least, 
> or more likely 7 + 6(n-1) (assuming we do simulcast and do it on a 
> separate RTP/RTCP stream).  It also means 4 or 6 times the amount of 
> TURN ports needed by a service offering WebRTC. (One day, ICE and TURN 
> will die the horrible death they should when IPV6 is the norm - but 
> even then it may be needed for things like firewalls that block UDP.)
>
> This drives a) RTP/RTCP mux (already being done, and predates WebRTC), 
> and BUNDLE.  With both, you can get 2 or 1 ports for a conference 
> (depending on if you bundle the DataChannel flow).

Amplifying my own point, this clearly impacts a lot of important 
performance aspects of media exchange.  Classically people answered 
handsets and it takes time to get them to the ear/mouth; that gave you 
100-500ms to finish call setup after "accept".  With GUIs and headsets 
or speakerphones, people will press and say "hello"; at best you have 
150ms. I've found you'll get clipping in speakerphones with 
press-to-accept if streams aren't flowing in 200ms, preferably less.  
300ms is quite noticeable.

Sometimes you can hide this delay by warming up channels before the user 
accepts.  However, that's not always possible, and also may fall afoul 
of other requirements (avoiding exposing physical location by IP without 
user interaction, avoid DoS attacks (incoming request produces a burst 
of ICE traffic in response as well as port reservations in the 
firewall), etc).

Also, there are more chances you'll run into port conflicts that cause 
NATs to switch "mode"; some non-symmetric NATs will port-preserve if 
it's not in-use/mapped, but when forced to map to another port will 
switch to symmetric NAT.  Really.  So with a large number of ports you 
might get different characteristics in the NAT (some requiring TURN, 
some not), and also even in simpler cases if there are multiple network 
interfaces you might end up with some ports on one interface and some on 
another, or some randomly deciding that a longer-delay candidate is 
better, etc.  The odds get worse the larger the number of ports.


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


From dave.taht@gmail.com  Fri Jan 24 08:38:47 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F409C1A04DD for ; Fri, 24 Jan 2014 08:38:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSE3A8tjNVaY for ; Fri, 24 Jan 2014 08:38:44 -0800 (PST)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 404F01A04C8 for ; Fri, 24 Jan 2014 08:38:44 -0800 (PST)
Received: by mail-ig0-f173.google.com with SMTP id c10so3020540igq.0 for ; Fri, 24 Jan 2014 08:38:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+jU5/HWuUMseJAnvfe2EECWzuQTfymbSAPfE8qfGrtY=; b=xPJNHslI3RHzedSb1VuINjUi46WxOPVnW9e02PKg0WSmGj4QjzvaGBDVw8sleYyu0F rwqZVXXF+hP0+QYvHokiJglYpavBK6w1TlxqT6YYnuW/n8cc8UmnvdGmHuNTh9Kw25zR 9h6b8BE1P/yymeGepmjsC0z8g0QTwHi2bJq9kY9AJMVkGYUoOwiPvVeoGs5NoJ+adk4I UXCgycDD3VXpir+5/wAmZ7T+XFKxqXG36UNrtRcuILrJaIVmszN2995RKN0s23Ryme0t 5LDs6wxzA1ig8EtTIq5y0TEo0pG46Hf15Ao3tNpGwv3CBSOFIspEp+qm6fNCIHZo55F0 tu5g==
MIME-Version: 1.0
X-Received: by 10.50.79.228 with SMTP id m4mr5267518igx.47.1390581522986; Fri, 24 Jan 2014 08:38:42 -0800 (PST)
Received: by 10.64.145.67 with HTTP; Fri, 24 Jan 2014 08:38:42 -0800 (PST)
In-Reply-To: <52E2900A.5040804@jesup.org>
References:  <52C17E9F.8060703@alvestrand.no>  <52C60213.9000401@alvestrand.no>   <52E0141F.4060805@jesup.org> <52E2900A.5040804@jesup.org>
Date: Fri, 24 Jan 2014 11:38:42 -0500
Message-ID: 
From: Dave Taht 
To: Randell Jesup 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "rmcat@ietf.org" 
Subject: Re: [rmcat] 5 tuples and rmcat-cc-requirements-01
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 16:38:47 -0000

On Fri, Jan 24, 2014 at 11:08 AM, Randell Jesup  wr=
ote:
> On 1/22/2014 1:55 PM, Randell Jesup wrote:
>>
>> I'm going to make deeper comments once I read through everything, but so=
me
>> detail points while I have them in front of me:
>>
>> One big issue for bundle is that ICE takes time, and it takes time
>> proportional to the number of ports you have to open.  From experience, =
the
>> more ports needing to be opened the more probably you can get.  For
>> Hangout-like conferencing, "classic" RTP setup would mean 5 + 4(n-1) por=
ts
>> where N is the number of participants at least, or more likely 7 + 6(n-1=
)
>> (assuming we do simulcast and do it on a separate RTP/RTCP stream).  It =
also
>> means 4 or 6 times the amount of TURN ports needed by a service offering
>> WebRTC. (One day, ICE and TURN will die the horrible death they should w=
hen
>> IPV6 is the norm - but even then it may be needed for things like firewa=
lls
>> that block UDP.)
>>
>> This drives a) RTP/RTCP mux (already being done, and predates WebRTC), a=
nd
>> BUNDLE.  With both, you can get 2 or 1 ports for a conference (depending=
 on
>> if you bundle the DataChannel flow).
>
>
> Amplifying my own point, this clearly impacts a lot of important performa=
nce
> aspects of media exchange.  Classically people answered handsets and it
> takes time to get them to the ear/mouth; that gave you 100-500ms to finis=
h
> call setup after "accept".  With GUIs and headsets or speakerphones, peop=
le
> will press and say "hello"; at best you have 150ms. I've found you'll get
> clipping in speakerphones with press-to-accept if streams aren't flowing =
in
> 200ms, preferably less.  300ms is quite noticeable.
>
> Sometimes you can hide this delay by warming up channels before the user
> accepts.  However, that's not always possible, and also may fall afoul of
> other requirements (avoiding exposing physical location by IP without use=
r
> interaction, avoid DoS attacks (incoming request produces a burst of ICE
> traffic in response as well as port reservations in the firewall), etc).
>
> Also, there are more chances you'll run into port conflicts that cause NA=
Ts
> to switch "mode"; some non-symmetric NATs will port-preserve if it's not
> in-use/mapped, but when forced to map to another port will switch to
> symmetric NAT.  Really.  So with a large number of ports you might get
> different characteristics in the NAT (some requiring TURN, some not), and
> also even in simpler cases if there are multiple network interfaces you
> might end up with some ports on one interface and some on another, or som=
e
> randomly deciding that a longer-delay candidate is better, etc.  The odds
> get worse the larger the number of ports.

I am beginning to feel a lot more of your pain. :/

However I still stand by

A) wanting to ensure that requirements driven by ICE/turn/nat negotiation
hassles don't affect direct e2e problems, and to ensure the API exposes
the ability to do saner things e2e in the absence of of
ice/turn/nat/middleboxes,
and (especially) over ipv6.

B) wanting to clearly separate audio and video tuples.

C) wanting world peace.

D) from a congestion control and analysis perspective I'd dearly like
to be able to
work without all these middleboxware for a while, and it is also coming
clear to me that I'd like to take a hard look at their behaviors also.

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



--=20
Dave T=E4ht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.=
html

From mirja.kuehlewind@ikr.uni-stuttgart.de  Fri Jan 24 08:56:42 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B941A0026 for ; Fri, 24 Jan 2014 08:56:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.085
X-Spam-Level: 
X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SPy6jZw0HDC for ; Fri, 24 Jan 2014 08:56:40 -0800 (PST)
Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4797B1A0016 for ; Fri, 24 Jan 2014 08:56:40 -0800 (PST)
Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 800806028A; Fri, 24 Jan 2014 17:56:36 +0100 (CET)
Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 7CEB860281; Fri, 24 Jan 2014 17:56:36 +0100 (CET)
From: Mirja Kuehlewind 
Organization: University of Stuttgart (Germany), IKR
To: rmcat@ietf.org
Date: Fri, 24 Jan 2014 17:56:36 +0100
User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316)
References:  <52E0141F.4060805@jesup.org> <52E2900A.5040804@jesup.org>
In-Reply-To: <52E2900A.5040804@jesup.org>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <201401241756.36480.mirja.kuehlewind@ikr.uni-stuttgart.de>
Cc: Randell Jesup 
Subject: Re: [rmcat] 5 tuples and rmcat-cc-requirements-01
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 16:56:43 -0000

Hi,

one more comment on the requirements that just came to my mind while readin=
g=20
this: To be able to quickly grab capacity, other flows on the link, that=20
might already utilize the link fully, need also to release capacity quickly=
=2E=20
Of course we cannot change existing congestion control but we can at least=
=20
require this for rmcat. The document already says that the flow should adap=
t=20
quickly but this is more or less just referred to case where more bandwidth=
=20
becomes available. Sensing that the traffic situation changed and now more=
=20
flows are competing is much harder and thus I would maybe have this as a=20
separate requirement.

By the way: are the requirements currently ordered by priority? Or is there=
 a=20
specific order? This should maybe be explained at the beginning. And if the=
re=20
is some kind of priority, I would see requirement 10 on the startup behavio=
r=20
somewhere at the beginning (right after low delay and competing with other=
=20
TCPs).

Mirja


On Friday 24 January 2014 17:08:42 Randell Jesup wrote:
> On 1/22/2014 1:55 PM, Randell Jesup wrote:
> > I'm going to make deeper comments once I read through everything, but
> > some detail points while I have them in front of me:
> >
> > One big issue for bundle is that ICE takes time, and it takes time
> > proportional to the number of ports you have to open.  From
> > experience, the more ports needing to be opened the more probably you
> > can get.  For Hangout-like conferencing, "classic" RTP setup would
> > mean 5 + 4(n-1) ports where N is the number of participants at least,
> > or more likely 7 + 6(n-1) (assuming we do simulcast and do it on a
> > separate RTP/RTCP stream).  It also means 4 or 6 times the amount of
> > TURN ports needed by a service offering WebRTC. (One day, ICE and TURN
> > will die the horrible death they should when IPV6 is the norm - but
> > even then it may be needed for things like firewalls that block UDP.)
> >
> > This drives a) RTP/RTCP mux (already being done, and predates WebRTC),
> > and BUNDLE.  With both, you can get 2 or 1 ports for a conference
> > (depending on if you bundle the DataChannel flow).
>
> Amplifying my own point, this clearly impacts a lot of important
> performance aspects of media exchange.  Classically people answered
> handsets and it takes time to get them to the ear/mouth; that gave you
> 100-500ms to finish call setup after "accept".  With GUIs and headsets
> or speakerphones, people will press and say "hello"; at best you have
> 150ms. I've found you'll get clipping in speakerphones with
> press-to-accept if streams aren't flowing in 200ms, preferably less.
> 300ms is quite noticeable.
>
> Sometimes you can hide this delay by warming up channels before the user
> accepts.  However, that's not always possible, and also may fall afoul
> of other requirements (avoiding exposing physical location by IP without
> user interaction, avoid DoS attacks (incoming request produces a burst
> of ICE traffic in response as well as port reservations in the
> firewall), etc).
>
> Also, there are more chances you'll run into port conflicts that cause
> NATs to switch "mode"; some non-symmetric NATs will port-preserve if
> it's not in-use/mapped, but when forced to map to another port will
> switch to symmetric NAT.  Really.  So with a large number of ports you
> might get different characteristics in the NAT (some requiring TURN,
> some not), and also even in simpler cases if there are multiple network
> interfaces you might end up with some ports on one interface and some on
> another, or some randomly deciding that a longer-delay candidate is
> better, etc.  The odds get worse the larger the number of ports.



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

tel: +49(0)711/685-67973
email: mirja.kuehlewind@ikr.uni-stuttgart.de
web: www.ikr.uni-stuttgart.de
=2D------------------------------------------------------------------

From randell-ietf@jesup.org  Fri Jan 24 14:59:09 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567601A01E5 for ; Fri, 24 Jan 2014 14:59:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72kRJfXuXYHG for ; Fri, 24 Jan 2014 14:59:07 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 249E71A0154 for ; Fri, 24 Jan 2014 14:59:06 -0800 (PST)
Received: from pool-173-49-144-199.phlapa.fios.verizon.net ([173.49.144.199]:3032 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1W6piK-0000JS-CU for rmcat@ietf.org; Fri, 24 Jan 2014 16:59:05 -0600
Message-ID: <52E2F022.5080509@jesup.org>
Date: Fri, 24 Jan 2014 17:58:42 -0500
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: rmcat@ietf.org
References:  <52E0141F.4060805@jesup.org> <52E2900A.5040804@jesup.org> <201401241756.36480.mirja.kuehlewind@ikr.uni-stuttgart.de>
In-Reply-To: <201401241756.36480.mirja.kuehlewind@ikr.uni-stuttgart.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Authenticated-Sender: randell@jesup.org
X-OutGoing-Spam-Status: No, score=-6.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org
Subject: Re: [rmcat] 5 tuples and rmcat-cc-requirements-01
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 22:59:09 -0000

On 1/24/2014 11:56 AM, Mirja Kuehlewind wrote:
> one more comment on the requirements that just came to my mind while reading
> this: To be able to quickly grab capacity, other flows on the link, that
> might already utilize the link fully, need also to release capacity quickly.
> Of course we cannot change existing congestion control but we can at least
> require this for rmcat.

Yes, though I'll note that releasing capacity quickly is almost always a 
requirement to avoid big problems (triply so for realtime code that 
doesn't want to build queues).  If you don't release fast, you are in 
deep trouble fast unless you're just a tiny bit over-bandwidth.  My 
algorithm tried to estimate how far it was over (by the slope of the 
apparent queue (delay) increase), and modify how far it cut back 
according to that (22ms per 20ms packet implies ~10% over-bandwidth, so 
cut bandwidth by (say) 15% immediately). (Yes, real stuff would be more 
complex, but you get the idea.) Better to overshoot on cutback; and this 
tends to help self-fairness as well, especially if there are different 
rules fr established flows compared to new ones.

> The document already says that the flow should adapt
> quickly but this is more or less just referred to case where more bandwidth
> becomes available. Sensing that the traffic situation changed and now more
> flows are competing is much harder and thus I would maybe have this as a
> separate requirement.

I'll look.  Much of this is implicit in the requirement to keep delay 
down and to not block new flows from getting a share.

> By the way: are the requirements currently ordered by priority? Or is there a
> specific order? This should maybe be explained at the beginning. And if there
> is some kind of priority, I would see requirement 10 on the startup behavior
> somewhere at the beginning (right after low delay and competing with other
> TCPs).

They are not in priority order; I think priorities are a judgement call 
and part of the WG's job in evaluating the results; there are tradeoffs 
between all of these in every algorithm, and it's the overall result 
that's important, not really the sub-pieces on their own.  (IMHO).

   Randell

>
> Mirja
>
>
> On Friday 24 January 2014 17:08:42 Randell Jesup wrote:
>> On 1/22/2014 1:55 PM, Randell Jesup wrote:
>>> I'm going to make deeper comments once I read through everything, but
>>> some detail points while I have them in front of me:
>>>
>>> One big issue for bundle is that ICE takes time, and it takes time
>>> proportional to the number of ports you have to open.  From
>>> experience, the more ports needing to be opened the more probably you
>>> can get.  For Hangout-like conferencing, "classic" RTP setup would
>>> mean 5 + 4(n-1) ports where N is the number of participants at least,
>>> or more likely 7 + 6(n-1) (assuming we do simulcast and do it on a
>>> separate RTP/RTCP stream).  It also means 4 or 6 times the amount of
>>> TURN ports needed by a service offering WebRTC. (One day, ICE and TURN
>>> will die the horrible death they should when IPV6 is the norm - but
>>> even then it may be needed for things like firewalls that block UDP.)
>>>
>>> This drives a) RTP/RTCP mux (already being done, and predates WebRTC),
>>> and BUNDLE.  With both, you can get 2 or 1 ports for a conference
>>> (depending on if you bundle the DataChannel flow).
>> Amplifying my own point, this clearly impacts a lot of important
>> performance aspects of media exchange.  Classically people answered
>> handsets and it takes time to get them to the ear/mouth; that gave you
>> 100-500ms to finish call setup after "accept".  With GUIs and headsets
>> or speakerphones, people will press and say "hello"; at best you have
>> 150ms. I've found you'll get clipping in speakerphones with
>> press-to-accept if streams aren't flowing in 200ms, preferably less.
>> 300ms is quite noticeable.
>>
>> Sometimes you can hide this delay by warming up channels before the user
>> accepts.  However, that's not always possible, and also may fall afoul
>> of other requirements (avoiding exposing physical location by IP without
>> user interaction, avoid DoS attacks (incoming request produces a burst
>> of ICE traffic in response as well as port reservations in the
>> firewall), etc).
>>
>> Also, there are more chances you'll run into port conflicts that cause
>> NATs to switch "mode"; some non-symmetric NATs will port-preserve if
>> it's not in-use/mapped, but when forced to map to another port will
>> switch to symmetric NAT.  Really.  So with a large number of ports you
>> might get different characteristics in the NAT (some requiring TURN,
>> some not), and also even in simpler cases if there are multiple network
>> interfaces you might end up with some ports on one interface and some on
>> another, or some randomly deciding that a longer-delay candidate is
>> better, etc.  The odds get worse the larger the number of ports.
>
-- 
Randell Jesup -- rjesup a t mozilla d o t com


From p.ohanlon@gmail.com  Wed Jan 29 07:23:02 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFD71A0456 for ; Wed, 29 Jan 2014 07:23:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bD9cdSvQLYme for ; Wed, 29 Jan 2014 07:22:59 -0800 (PST)
Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id D99C31A0443 for ; Wed, 29 Jan 2014 07:22:58 -0800 (PST)
Received: by mail-wg0-f54.google.com with SMTP id x13so3883295wgg.9 for ; Wed, 29 Jan 2014 07:22:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=czUzyTvPRWesTmICoA9+QgzDeGiWSkyWpIi3O+/hq6M=; b=UrKwxmHwjLdcaBND/kr5QdGd8DVcgRZxka9/rzeKUPKTvyIP5/OfD/exT2+9LOPKde GDEpKiT45D0rwwb5EhICCwyRBXx7aFcg8fhz7duKK9iGv2HAs+4+I2ZYPlDgiiCjPlNE 6AcfHSRh7jCtb34ngK5wdkZfhDirRxqg7sqK0Q5vd3HhEjAbFZmBJpmSaLXrTZfA7Zsj iVGJ1IvqFTVpMljVeY/mTcEYt17LsiQFrmzTxhHhmMZhZIQEaCzL+RDw8sgSxzkzjjNE vGN11RYqrd+cQTrk5khHOZFXFK2RFPG0haBtCfKquPYVzBtddRXSwrO/FU6XkqX1tCoV D8Fg==
X-Received: by 10.180.9.232 with SMTP id d8mr19834009wib.25.1391008975577; Wed, 29 Jan 2014 07:22:55 -0800 (PST)
Received: from [192.168.1.109] ([149.241.139.74]) by mx.google.com with ESMTPSA id z1sm5495086wjq.19.2014.01.29.07.22.52 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Jan 2014 07:22:52 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Piers O'Hanlon 
X-Priority: 5
In-Reply-To: <16C12C4C-9E7C-4551-8D9F-0693E77D0DA2@netapp.com>
Date: Wed, 29 Jan 2014 15:22:50 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <7E50030C-4E5B-4185-9AA8-6AEE50BE1476@netapp.com> <6BF44A6D-215B-4F02-9E9A-74B00BC4DADE@ifi.uio.no> <16C12C4C-9E7C-4551-8D9F-0693E77D0DA2@netapp.com>
To: rmcat WG 
X-Mailer: Apple Mail (2.1283)
Subject: Re: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jan 2014 15:23:03 -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

On 21 Jan 2014, at 12:53, Eggert, Lars wrote:

> On 2014-1-16, at 15:31, Michael Welzl  wrote:
>> I vote for adoption.
>=20
> Anyone else care to state an opinion?
>=20
> Thanks,
> Lars


From lars@netapp.com  Fri Jan 31 02:41:28 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7051A0580 for ; Fri, 31 Jan 2014 02:41:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vip-Av5ZZvpw for ; Fri, 31 Jan 2014 02:41:26 -0800 (PST)
Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9B70C1A0571 for ; Fri, 31 Jan 2014 02:41:26 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.95,757,1384329600";  d="asc'?scan'208";a="99297211"
Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx11-out.netapp.com with ESMTP; 31 Jan 2014 02:41:23 -0800
Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Fri, 31 Jan 2014 02:41:23 -0800
From: "Eggert, Lars" 
To: rmcat WG 
Thread-Topic: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
Thread-Index: AQHPEpYXwCGFx0stw0qE8XczVDv3zJqH8DYAgAfAX4CADLxMAIAC1gUA
Importance: low
X-Priority: 5
Date: Fri, 31 Jan 2014 10:41:22 +0000
Message-ID: <9E47530C-2D39-476C-A53F-3CBEF451A267@netapp.com>
References: <7E50030C-4E5B-4185-9AA8-6AEE50BE1476@netapp.com> <6BF44A6D-215B-4F02-9E9A-74B00BC4DADE@ifi.uio.no> <16C12C4C-9E7C-4551-8D9F-0693E77D0DA2@netapp.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.106.53.51]
Content-Type: multipart/signed; boundary="Apple-Mail=_C4B81990-8B5C-449A-AC10-48D864A75193"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Cc: "draft-singh-rmcat-cc-eval@tools.ietf.org" 
Subject: Re: [rmcat] WG adoption of draft-singh-rmcat-cc-eval?
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Jan 2014 10:41:28 -0000

--Apple-Mail=_C4B81990-8B5C-449A-AC10-48D864A75193
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

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

--Apple-Mail=_C4B81990-8B5C-449A-AC10-48D864A75193
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQCVAwUBUut90tZcnpRveo1xAQLgFQP/XDxx5ykEUeE3ziAvhcDFlHyLbtc0tyrU
A2/aReQRwQKZ3addffnPSBvmcwuNMwUI3ALY6AkGQ/hTobdVoJCq4KnFW3WoDuYF
TbtAQrj+AjAWmLMKS0hKmMbjx2LA3WkLclvgrTBVr23kXSSb7Zb7Nm/FYzhZiBvY
0jvFxpnfIBM=
=O/SD
-----END PGP SIGNATURE-----

--Apple-Mail=_C4B81990-8B5C-449A-AC10-48D864A75193--

From internet-drafts@ietf.org  Fri Jan 31 04:10:09 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1370C1A05A7; Fri, 31 Jan 2014 04:10:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkAIWmoA62IG; Fri, 31 Jan 2014 04:10:07 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD87F1A0598; Fri, 31 Jan 2014 04:10:07 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.90.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140131121007.1823.87763.idtracker@ietfa.amsl.com>
Date: Fri, 31 Jan 2014 04:10:07 -0800
Cc: rmcat@ietf.org
Subject: [rmcat] I-D Action: draft-ietf-rmcat-eval-criteria-00.txt
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Jan 2014 12:10:09 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the RTP Media Congestion Avoidance Techniques=
 Working Group of the IETF.

        Title           : Evaluating Congestion Control for Interactive Rea=
l-time Media
        Authors         : Varun Singh
                          Joerg Ott
	Filename        : draft-ietf-rmcat-eval-criteria-00.txt
	Pages           : 19
	Date            : 2014-01-31

Abstract:
   The Real-time Transport Protocol (RTP) is used to transmit media in
   telephony and video conferencing applications.  This document
   describes the guidelines to evaluate new congestion control
   algorithms for interactive point-to-point real-time media.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rmcat-eval-criteria/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rmcat-eval-criteria-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/