IETF Logo Mail Archive

Re: [ledbat] WG last call on draft-ietf-ledbat-congestion-08

Padma Bhooma <bhooma@apple.com> Wed, 19 October 2011 05:00 UTC

Return-Path: <bhooma@apple.com>
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 B753F11E8083 for <ledbat@ietfa.amsl.com>; Tue, 18 Oct 2011 22:00:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.426
X-Spam-Level:
X-Spam-Status: No, score=-106.426 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 UwVRXAWHfetA for <ledbat@ietfa.amsl.com>; Tue, 18 Oct 2011 22:00:23 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2261511E8080 for <ledbat@ietf.org>; Tue, 18 Oct 2011 22:00:19 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_+ckLzYkDTicPnCgDPFpFXw)"
Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LTA00K0UR8B5BM1@mail-out.apple.com> for ledbat@ietf.org; Tue, 18 Oct 2011 22:00:17 -0700 (PDT)
X-AuditID: 11807130-b7c1bae000001553-37-4e9e595fe588
Received: from [17.153.35.95] (Unknown_Domain [17.153.35.95]) by relay11.apple.com (Apple SCV relay) with SMTP id 0A.A2.05459.0695E9E4; Tue, 18 Oct 2011 22:00:17 -0700 (PDT)
From: Padma Bhooma <bhooma@apple.com>
In-reply-to: <8D52A245-9713-4EB7-AE30-CA4B569FF774@office.hd>
Date: Tue, 18 Oct 2011 22:00:16 -0700
Message-id: <C0A44569-CFF3-489F-B0D7-B6A21569601C@apple.com>
References: <2D481290-12BA-4101-81A1-07FF95A7CD29@apple.com> <8D52A245-9713-4EB7-AE30-CA4B569FF774@office.hd>
To: Rolf Winter <Rolf.Winter@neclab.eu>
X-Mailer: Apple Mail (2.1247)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMIsWRmVeSWpSXmKPExsUiOFM5Xjcxcp6fwZo5Ehb/Hj1ns3h/9yWr A5PHkiU/mTxmHHvJHsAUxWWTkpqTWZZapG+XwJVxrEmo4Okx9orfjzeyNzB+WMbexcjBISFg IjHth0gXIyeQKSZx4d56ti5GLg4hgfWMEj9nv2AGqREWcJWY06kMUsMrYCjxc/I6JhCbWSBB YtH1lewgNpuAqsTJP3eYQWxOAVuJhqMvwGwWoPizSU+YIerVJd73zmCHmGMjceHdXzYQW0gg V2L91SesILYIUM2S96dYIe6RlXj39g3bBEa+WUhWz0KyGsLWlli28DXzLKBLmQV0JCYvZIQI F0n8uP8ATQmE/fH8EagxihJTuh9C1ZhLfPyznRXCTpT4eqSNBWKki8SRb+aoykHCphJHLkpA hOMlVnd1s8JUdx8KxDTcTOL/xW1QB7hI/Luwgg3GXrx6B9sCRuFVjIJFqTmJlYaGeokFBTmp esn5uZsYQVHdUGiwg3HtT/5DjAIcjEo8vFxS8/yEWBPLiitzDzFKcDArifCujwAK8aYkVlal FuXHF5XmpBYfYpTmYFES5+XvmesnJJCeWJKanZpakFoEk2Xi4JRqYDQ4oRn6dKVAYfC0qd/L 7jMZTp+jPvPc9Lpbap7e/Q/n7bYUk1tT/FCh5Fh7yArDwNWFkhOWWxrsXPP+aOrVYtVJU6ek L2pWSfAMTc9t557KmrFhQeeyX+LrfhxbdXw2q8Bz7Vm5DOW3akIm6i/OP5RulN1g4+uyKUHk WN1DTkUH4f6OOI9IDSWW4oxEQy3mouJEAG0Y+eDmAgAA
Cc: "ledbat@ietf.org" <ledbat@ietf.org>
Subject: Re: [ledbat] WG last call on draft-ietf-ledbat-congestion-08
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: Wed, 19 Oct 2011 05:00:24 -0000

We have done measurements to see how LEDBAT will behave on wireless links under different kinds of network conditions. Our main
emphasis was to see improvement in response time and throughput for a competing flow when there is a LEDBAT upload in 
progress compared to a standard TCP flow in progress. 

For instance, the following graph shows how web page load times to different websites changed when a standard TCP upload (blue)
or LEDBAT (green) or no upload flow (yellow) was in progress to another host. The numbers with LEDBAT are very close to having
no upload and they show a huge improvement in response time. The Y-axis is page load times in milliseconds.






Here is another graph for similar measurements on 3G:




Another important goal for LEDBAT is to make sure that a LEDBAT flow will yield to a standard TCP flow when they have to share 
the link. Here is a graph to show how two LEDBAT flows (Flow A and Flow B marked as bk) yielded to another loss-based TCP flow:




Overall, we have observed that using LEDBAT as a congestion control algorithm improves response time for other 
applications which is very desirable in some scenarios.

Thanks,
Padma


On Oct 14, 2011, at 11:07 AM, Rolf Winter wrote:

> This is awesome news. Have you done measurements with the implementation that you can share?
> 
> 
> 
> On 12.10.2011, at 01:40, "Padma Bhooma" <bhooma@apple.com> wrote:
> 
>> Hi,
>> 
>> I reviewed the latest draft and I have few comments on the latest changes. A receiver may have to echo the remote timestamp to allow for computation of RTT which it can use for computing CTO. It might be useful to mention that the sender is supposed to retransmit sent data or transmit new data to restart the ACK clock.
>> 
>> Other than the comments above I think the algorithm is ready for adoption.
>> 
>> The implementation of LEDBAT algorithm that was done as a TCP Congestion control module in Mac OS X is available at the following link:
>> http://opensource.apple.com/source/xnu/xnu-1699.22.81/bsd/netinet/tcp_ledbat.c
>> 
>> Thanks,
>> Padma
>> 
>> 
>> 
>> 
>> _______________________________________________
>> ledbat mailing list
>> ledbat@ietf.org
>> https://www.ietf.org/mailman/listinfo/ledbat

v2.23.0 | Report a Bug | By Email