Re: [ledbat] [R-C] LEDBAT vs RTCWeb

Randell Jesup <randell-ietf@jesup.org> Tue, 24 April 2012 22:02 UTC

Return-Path: <randell-ietf@jesup.org>
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B614111E8074 for <ledbat@ietfa.amsl.com>; Tue, 24 Apr 2012 15:02:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.063
X-Spam-Level:
X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvuoEvPklAxt for <ledbat@ietfa.amsl.com>; Tue, 24 Apr 2012 15:02:52 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 38D1321F85E1 for <ledbat@ietf.org>; Tue, 24 Apr 2012 15:02:52 -0700 (PDT)
Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1SMnop-0003A3-FG; Tue, 24 Apr 2012 17:02:43 -0500
Message-ID: <4F9722D5.2020105@jesup.org>
Date: Tue, 24 Apr 2012 18:01:57 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: Rolf Winter <Rolf.Winter@neclab.eu>
References: <4F840709.4020103@alvestrand.no> <CAEdus3+Muyy73UoXYuNv6K3OqaSnUYkZh5yBYcpOT1M4oqBc3w@mail.gmail.com> <4F87EF2B.1010805@jesup.org> <201204201355.36264.mirja.kuehlewind@ikr.uni-stuttgart.de> <4F91772F.8010806@jesup.org> <791AD3077F94194BB2BDD13565B6295D2509B178@Polydeuces.office.hd> <4F958A16.6070505@jesup.org> <791AD3077F94194BB2BDD13565B6295D2509C952@Polydeuces.office.hd> <4F95D01B.1020003@jesup.org> <791AD3077F94194BB2BDD13565B6295D2509E0F0@Polydeuces.office.hd>
In-Reply-To: <791AD3077F94194BB2BDD13565B6295D2509E0F0@Polydeuces.office.hd>
Content-Type: multipart/alternative; boundary="------------070004050507080505090901"
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-Source:
X-Source-Args:
X-Source-Dir:
Cc: "ledbat@ietf.org" <ledbat@ietf.org>, "rtp-congestion@alvestrand.no" <rtp-congestion@alvestrand.no>
Subject: Re: [ledbat] [R-C] LEDBAT vs RTCWeb
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mailing list of the LEDBAT WG <ledbat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ledbat>, <mailto:ledbat-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ledbat>
List-Post: <mailto:ledbat@ietf.org>
List-Help: <mailto:ledbat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ledbat>, <mailto:ledbat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Apr 2012 22:02:53 -0000

On 4/24/2012 4:35 PM, Rolf Winter wrote:
>> We know when faced with deep buffers and large loss-based flow, a delay
>> flow will lose or have to transition to loss-based and live with delay
>> (see Cx-TCP).  We also know that in practice, the (residential)
>> bottleneck links are almost always the access link (DSL, fiber, etc) or
>> sometimes the WiFi connection. Corporate/educational can be a bit
>> different, but there's a better chance of AQM or service-based traffic
>> shaping there.
>>
>> We can deal (mostly) with fighting with TCP and expected it.  We didn't
>> expect scavenger protocols to be pumping the queues up when TCP is idle
>> or bursty.
> Here is where you lose me a bit. How do you "fight" TCP and its queue build-up exactly. I don't think we talk about protocols with the same design goals, are we. One of LEDBAT's design goals e.g. is to use all available bandwidth.

Our (WebRTC/RRTCC's) primary constraints are to a) keep delay near 0, b) 
use a 'fair' share of bandwidth (all available if the other flows don't 
use all the available bandwidth).  Low delay generally takes precedence 
over bandwidth, though eventually we hit a wall and can't reasonably 
reduce bandwidth more.

The design goals are not identical to LEDBAT; but these protocols need 
to share the network "well" with each other and TCP (and inflexible UDP 
flows like classic VoIP).  TCP is a given (unfortunately), and drop-tail 
routers with deep buffers are also a given (very unfortunately, 
especially with TCP).

We can't stop TCP from grabbing all buffers; though there may be limited 
ability to "knock TCP back" some periodically when there are a small 
number of competing TCP flows, at the costs of delay bursts - but that 
probably isn't practical (a usable experience) for users.

>> I note that LEDBAT is now in Linux and MacOS, so it's not just in
>> application code anymore, and app developers (even OS developers) may
>> assume it's safe to blindly use without user involvement.  (And even if
>> informed, assuming users understand the interaction of protocols is ...
>> a stretch.)
> And I think it is good that LEDBAT sees some deployment. It is an experimental congestion control algorithm. These experiments will provide us with good feedback and we might need to revisit some design decisions. There are millions of deployed LEDBAT-enabled clients out there and unfortunately the only thing we know about this "experiment" is that the experimenters have assured us that LEDBAT was deployed with "good success".

Millions != experiments.  This is wide-scale deployment, and implying it 
isn't is misleading (as will deployment of WebRTC).  And implementation 
in core OS/X and Linux one assumes will lead to use by OS functions and 
applications such as cloud file backup, app update, etc.

So if this "breaks" the network, we have a problem.

>> Note that no routers are likely to recognize rtcweb traffic as VoIP
>> since the signaling is opaque and application-dependant, so ALGs and
>> the like have nothing to work against.  It would have to 'guess' that
>> the packet stream leading byte pattern and STUN/ICE traffic signified
>> use of the port for VoIP.  Eventually they may learn, but it will take
>> years.
>>
>> I stand by the contention this is a real, significant problem which
>> could get far worse if non-user-centric services start using LEDBAT.
> Maybe, but the alternative protocol that these apps you describe above can use is TCP. I remain unconvinced that TCP makes the problem less severe than LEDBAT would.

I think this is a false dichotomy, in that there are other choices for 
such applications, such as TFRC, RRTCC (which we're defining), 
TCP-Vegas(?), Cx-TCP (which in testing was ~20ms delay, but switches to 
loss-based fair sharing when faced with TCP - modifying it can probably 
lead to it dropping to low BW when competing) and for that matter LEDBAT 
itself (or a variant thereof) with different tunings.

I believe RRTCC could cover a fair amount of of the goals of LEDBAT with 
alternate tunings, for example.

Let me be clear: *if* widespread LEDBAT use, especially by 
"background"/non-user-visible apps will cause major disruption of VoIP 
flows on the net (and in particular for flows from within the same 
residence or enterprise), then there's a real problem with encouraging 
deployment.  If it does not, then the issue is minor.  I also believe 
that we do not know the answer to this question currently, though I 
believe the answer it is that it will cause significant delay and 
quality loss, and we have some evidence to that effect.

Also (and I haven't checked this yet): how does LEDBAT respond to AQM?  
 From telecom-paristech.fr:

    The experimental work in [ITC22] exploits instead a own
    implementation and points that LEDBAT may not work as expected (and
    actually might be needed) in case active queue management techniques
    AQM are applied in user modems (the study also suggests AQM to
    become a default practice in set-top-box devices)

http://www.infres.enst.fr/~drossi/DATA/PRJ-Ledbat+AQM.pdf

It seems like AQM causes LEDBAT to promote to behavior similar to TCP, 
but with low delay.  Since it still seems fair, this is ok, but it's no 
longer a background or scavenger flow, and applications using it need to 
be aware they can impact "foreground" flows if AQM is in play.  Perhaps 
applications need to be given awareness when LEDBAT detects active AQM 
(if it can), and there's no "scavenger" CC algorithm for AQM that I know of.

-- 
Randell Jesup
randell-ietf@jesup.org