Re: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat-congestion-08.txt

Arjuna Sathiaseelan <arjuna@erg.abdn.ac.uk> Fri, 28 October 2011 16:10 UTC

Return-Path: <arjuna.sathiaseelan@gmail.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 1CD1321F89BA for <ledbat@ietfa.amsl.com>; Fri, 28 Oct 2011 09:10:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 hRkCOj21Euoe for <ledbat@ietfa.amsl.com>; Fri, 28 Oct 2011 09:10:48 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id B7DEC21F8B00 for <ledbat@ietf.org>; Fri, 28 Oct 2011 09:10:47 -0700 (PDT)
Received: by qadc10 with SMTP id c10so4785929qad.31 for <ledbat@ietf.org>; Fri, 28 Oct 2011 09:10:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nDMNwPo6PQNNlszQYZ1SiUQSHI1GF+7e92Fw9XLTivk=; b=DOYDNAgk+Ga+uGzdRHLZdy+5Ow/AO7PF0k2CmQujxKCF2aG3xtlR31/EseSnzIq6YI GwyvNy4ydLXjsNq/X1naUVKNs2CbRRnWUPe/6cOvPMVNxRXwEI9FDUGyDsDgWF+HAnoz P7nUjZCYJ7sMv2IX69bQbx5dGWcqYxYC+F6q0=
MIME-Version: 1.0
Received: by 10.229.13.11 with SMTP id z11mr870134qcz.115.1319818230965; Fri, 28 Oct 2011 09:10:30 -0700 (PDT)
Sender: arjuna.sathiaseelan@gmail.com
Received: by 10.229.28.196 with HTTP; Fri, 28 Oct 2011 09:10:30 -0700 (PDT)
In-Reply-To: <201110281552.50770.mirja.kuehlewind@ikr.uni-stuttgart.de>
References: <4E92338F.1030601@fandm.edu> <CAPaG1A=9Znd+MwH6Eac5BMe21cVhBAhDxJrWiBh4cJ737ahfWw@mail.gmail.com> <CAPaG1AmBkER8VZCkAGytBLntJUD5wcKtFaP7zuRh+26suK+JNA@mail.gmail.com> <201110281552.50770.mirja.kuehlewind@ikr.uni-stuttgart.de>
Date: Fri, 28 Oct 2011 17:10:30 +0100
X-Google-Sender-Auth: XSkoh2dC7ZyZu2Ld8bTZyZaT_k0
Message-ID: <CAPaG1A=ccYc-XDFo3XNrZjhkuL=g+tUuFEsL6OkCVr0KsFqekA@mail.gmail.com>
From: Arjuna Sathiaseelan <arjuna@erg.abdn.ac.uk>
To: Mirja Kuehlewind <mirja.kuehlewind@ikr.uni-stuttgart.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: ledbat@ietf.org
Subject: Re: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat-congestion-08.txt
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: Fri, 28 Oct 2011 16:10:55 -0000

Hello Mirja,
  How about this?

"LEDBAT takes the minimum delay it measures at any time as the base delay and
compares the current delay measurement to this value to calculate the queuing
delay. off_target compares the queuing delay to the chosen TARGET delay
and normalizes itself to the TARGET value."

Regards
Arjuna


On 28 October 2011 14:52, Mirja Kuehlewind
<mirja.kuehlewind@ikr.uni-stuttgart.de> wrote:
> Thanks, Arjuna.
>
> I added two sentences here:
> "LEDBAT takes the minimum delay it measures at any time as the base delay and
> compares the current delay measurement to this value to calculate the queuing
> delay. off_target compares the queuing delay to the dedicated TARGET chosen
> and is normalizes by the TARGET value itself."
>
> Does this work?
>
> Mirja
>
>
> On Saturday 15 October 2011 10:56:49 Arjuna Sathiaseelan wrote:
>> Another thing which I forgot to point out - in section 3.4.1 the term
>> off_target suddenly pops up without an explanation. That needs to be
>> resolved please.
>>
>> Regards
>> Arjuna
>>
>> On 15 October 2011 09:37, Arjuna Sathiaseelan <arjuna@erg.abdn.ac.uk> wrote:
>> > Dear Jana and others,
>> >
>> >  I went through the draft and am currently trying to figure out what
>> > the performance implications are with the latest draft through
>> > simulations (I have a few helpful UG students in India who have
>> > volunteered to do this for me - this includes modifying the current
>> > ns-2 code to reflect the latest draft). But unfortunately, I dont
>> > think we will be able to tell anything useful before WGLC ends!
>> >
>> > However I have one question ->
>> >  " A CTO is used to detect heavy congestion indicated by loss of all
>> >   outstanding data or acknowledgments, resulting in reduction of the
>> >   cwnd to 1 MSS and an exponential backoff of the CTO interval"
>> >
>> > So I am trying to see  whether heavy congestion actually means loss of
>> > "ALL" outstanding segments - so how does LEDBAT behave according to
>> > the current draft if atleast one packet went through? Just trying to
>> > understand.
>> >
>> > Regards
>> > Arjuna
>> >
>> > On 10 October 2011 00:51, Janardhan Iyengar <jana.iyengar@gmail.com>
> wrote:
>> >> Dear all,
>> >>
>> >> A new version of the congestion control draft is in the repository.
>> >> There are two major mods in this revision:
>> >>
>> >> 1/ WGLC identified one major issue that needed to be addressed in the
>> >> LEDBAT congestion control draft -- LEDBAT response to extreme congestion
>> >> -- and we've tried to address that issue in this revision. We've added a
>> >> new mechanism, the Congestion Timeout (CTO), for a sender to respond to
>> >> extreme congestion. We do not specify how this should be implemented,
>> >> but we do note that a CTO can be implemented with or without a timer. In
>> >> terms of textual changes, we've added an update_CTO() function and a
>> >> branch for what to do if no acks are received within a CTO amount of
>> >> time in Section 3.4.2. We have changed the response to data loss to
>> >> ensure that a protocol, such as TCP, that uses the same timer for both
>> >> congestion control and for
>> >> retransmissions, changes its cwnd correctly.
>> >>
>> >> 2/ We have set the values for INIT_CWND to 4 and MIN_CWND to 2, and have
>> >> clarified the discussion of CURRENT_DELAYS and INIT_CWND/MIN_CWND in
>> >> Section 3.5.
>> >>
>> >> Please comment!
>> >> - jana
>> >>
>> >> --
>> >> Janardhan Iyengar
>> >> Assistant Professor, Computer Science
>> >> Franklin & Marshall College
>> >> http://www.fandm.edu/jiyengar
>> >>
>> >>
>> >> -------- Original Message --------
>> >> Subject: New Version Notification for
>> >> draft-ietf-ledbat-congestion-08.txt Date: Sun, 09 Oct 2011 16:33:33
>> >> -0700
>> >> From: internet-drafts@ietf.org
>> >> To: jiyengar@fandm.edu
>> >> CC: jiyengar@fandm.edu, mirja.kuehlewind@ikr.uni-stuttgart.de,
>> >>  greg@bittorrent.com, shalunov@bittorrent.com
>> >>
>> >> A new version of I-D, draft-ietf-ledbat-congestion-08.txt has been
>> >> successfully submitted by Janardhan Iyengar and posted to the IETF
>> >> repository.
>> >>
>> >> Filename:        draft-ietf-ledbat-congestion
>> >> Revision:        08
>> >> Title:           Low Extra Delay Background Transport (LEDBAT)
>> >> Creation date:   2011-10-09
>> >> WG ID:           ledbat
>> >> Number of pages: 19
>> >>
>> >> Abstract:
>> >>   LEDBAT is an experimental delay-based congestion control algorithm
>> >>   that attempts to utilize the available bandwidth on an end-to-end
>> >>   path while limiting the consequent increase in queueing delay on the
>> >>   path.  LEDBAT uses changes in one-way delay measurements to limit
>> >>   congestion that the flow itself induces in the network.  LEDBAT is
>> >>   designed for use by background bulk-transfer applications; it is
>> >>   designed to be no more aggressive than TCP congestion control and to
>> >>   yield in the presence of any competing flows when latency builds,
>> >>   thus limiting interference with the network performance of the
>> >>   competing flows.
>> >>
>> >>
>> >>
>> >>
>> >> The IETF Secretariat
>> >> _______________________________________________
>> >> ledbat mailing list
>> >> ledbat@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/ledbat
>> >
>> > --
>> > http://about.me/arjuna.sathiaseelan
>>
>> _______________________________________________
>> ledbat mailing list
>> ledbat@ietf.org
>> https://www.ietf.org/mailman/listinfo/ledbat
>
>
>
> --
> -------------------------------------------------------------------
> Dipl.-Ing. Mirja Kühlewind
> Institute of Communication Networks and Computer Engineering (IKR)
> University of Stuttgart, Germany
> Pfaffenwaldring 47, D-70569 Stuttgart
>
> tel: +49(0)711/685-67973
> email: mirja.kuehlewind@ikr.uni-stuttgart.de
> web: www.ikr.uni-stuttgart.de
> -------------------------------------------------------------------
>