Re: [aqm] I-D Action: draft-ietf-aqm-pie-05.txt

"Rong Pan (ropan)" <ropan@cisco.com> Mon, 04 April 2016 19:13 UTC

Return-Path: <ropan@cisco.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957C612D7EA for <aqm@ietfa.amsl.com>; Mon, 4 Apr 2016 12:13:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Level:
X-Spam-Status: No, score=-14.531 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 Wzh2McJPJf4K for <aqm@ietfa.amsl.com>; Mon, 4 Apr 2016 12:13:45 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23EC012D80E for <aqm@ietf.org>; Mon, 4 Apr 2016 12:13:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9373; q=dns/txt; s=iport; t=1459797221; x=1461006821; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1DQc5edcLdN6Fv5onHbt1jkXswUBeN2YuQLEGvpXvFE=; b=NK2YZxTCPdVqo1o+bLaAzKenfoekfy3UUNF1wX3B7NmvLUdg3HJYDVuY dCgSqwZVVd6ajpHdi7zOVM6g/k2ZEEUIPE9aY2JmPNubJwLnEMd3bZU0Z AkJ12XFV08X/Rdp/nVFIQjVOiBSH9lqCZpokN3MI00qe8lfosxi56twQv s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D3AQCWvAJX/49dJa1dDoMpU30GuyEBDYFyFwqCPIMwAoE6OBQBAQEBAQEBZSeEQQEBAQQBAQEkRwsMBAIBCBEEAQEoBycLFAkIAgQBDQUbBIgHAQ6+OwEBAQEBAQEBAQEBAQEBAQEBAQEBARWGIIRKhAU4hVgFjgWJfAGFcogVgWhOg3+IWo8ZAR4BAUKCARyBDztshnI2AX0BAQE
X-IronPort-AV: E=Sophos;i="5.24,441,1454976000"; d="scan'208";a="90095435"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2016 19:13:36 +0000
Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u34JDaaq002360 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Apr 2016 19:13:36 GMT
Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 4 Apr 2016 14:13:35 -0500
Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1104.009; Mon, 4 Apr 2016 14:13:35 -0500
From: "Rong Pan (ropan)" <ropan@cisco.com>
To: Rasool Al-Saadi <ralsaadi@swin.edu.au>, "aqm@ietf.org" <aqm@ietf.org>
Thread-Topic: [aqm] I-D Action: draft-ietf-aqm-pie-05.txt
Thread-Index: AQHRc/cxYP/vIxkARkm//dWjIlRZzJ9lP4CAgBUDLoA=
Date: Mon, 04 Apr 2016 19:13:35 +0000
Message-ID: <D327F5CD.179B4%ropan@cisco.com>
References: <20160301201602.24979.59154.idtracker@ietfa.amsl.com> <6545444AE21C2749939E637E56594CEA3C1D01A0@gsp-ex02.ds.swin.edu.au>
In-Reply-To: <6545444AE21C2749939E637E56594CEA3C1D01A0@gsp-ex02.ds.swin.edu.au>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.2.160219
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [171.71.130.190]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <A88DADDCF738AA4D926DB65DCAA6365E@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/SH6Q9EppZVFbi_rRZElaVoISjKw>
Cc: Grenville Armitage <garmitage@swin.edu.au>
Subject: Re: [aqm] I-D Action: draft-ietf-aqm-pie-05.txt
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Apr 2016 19:13:47 -0000

Rasool,

Thanks for your detailed review. Please see the comments below and a new
draft has been posted.

Regards,

Rong

On 3/21/16, 8:20 PM, "aqm on behalf of Rasool Al-Saadi"
<aqm-bounces@ietf.org on behalf of ralsaadi@swin.edu.au> wrote:

>Dear all,
>
>Thank you for revising PIE Internet Draft as it has become much clearer
>than previous versions. However, I have some comments regarding then new
>draft:
>
>1) In page 12, section 5.2 (Departure Rate Estimation),
>
>>    current_qdelay = queue_.byte_length() *
>>                     PIE->avg_dq_time_/DQ_THRESHOLD;
>>
>
>This code assumes that DQ_THRESHOLD of bytes are de-queued during
>avg_dq_time , but this is not very accurate as we can de-queue
>DQ_THRESHOLD + MSS during the measurement cycle (the condition is
>PIE->dq_count_ > DQ_THRESHOLD). Are you trying to simplify the code or a
>very accurate current_qdelay calculation is not required?

>>>>>>>>>>>>>>>>RP: it is for simplification purpose and accurate latency
>>>>>>>>>>>>>>>>calculation is not required. It is probability-based
>>>>>>>>>>>>>>>>scheme, there are a lot of randomness built-in.


> 
>
>2) In the same section mentioned above,
>
>>    * Upon a packet deque:
>>
>>      if PIE->in_measurement_ == FALSE and queue.byte_length() >
>>      DQ_THRESHOLD:
>>         PIE->in_measurement_ = TRUE;
>>         PIE->measurement_start_ = now;
>>         PIE->dq_count_ = 0;
>>
>>      if PIE->in_measurement_ == TRUE:
>>         PIE->dq_count_ = PIE->dq_count_ + deque_pkt_size;
>>         if PIE->dq_count_ > DQ_THRESHOLD then
>>            weight = DQ_THRESHOLD/2^16
>>            PIE->avg_dq_time_ = (now-PIE->measurement_start_)*weight
>>                                + PIE->avg_dq_time_*(1-weight);
>>            PIE->dq_count_=0;
>>            PIE->measurement_start_ = now
>
>This code works correctly first time when in_measurement_== FALSE then,
>it will stay in measurement state even when there are no DQ_THRESHOLD
>worth of bytes in the queue. So, PIE->avg_dq_time_ will be wrong as it
>includes the time of filling the queue with DQ_THRESHOLD worth of bytes
>plus the time of de-queuing  it. The simple solution for that is just by
>changing the last two lines of the code:
>
>>            PIE->dq_count_=0;
>>            PIE->measurement_start_ = now
>
>By 
>         PIE->in_measurement_ = FALSE;
>
>BTW, the code in the end of the daft is correct.


>>>>>>>>>>>>>>>>>>RP: Pseudo code is correct, here is not the complete
>>>>>>>>>>>>>>>>>>code, merely to explain the key part of the algorithm. I
>>>>>>>>>>>>>>>>>>now add the else clause in to be clear.




>
>
>3) In page 16, section 6 (Implementation Cost), the paragraph that
>describes combing SFQ with PIE is not clear and confusing.
>
>"SFQ can also be combined with PIE to further improve latency for various
>flows with different priorities. If the timestamp is used to obtain
>queueing latency, PIE can be adopted directly to each individual queue.
>If the latency is obtained via the deque rate calculation, we recommend
>one PIE instance using the overall queue length divided by the overall
>deque rate. Then the overall PIE->drop_prob_ is modified using each
>individual queue divided by the maximum individual queue length: PIE-
>>drop_prob_(i)=queue_.byte_length(i)/max(queue_.byte_length(i)). "
>
>I am not sure if I interpreted the paragraph correctly or not.  It seems
>that there are two cases when using PIE with SFQ scheduler :
>1- When timestamp is used to calculate queue delay, each queue has a
>separate drop probability calculation background process  i.e. each queue
>uses normal PIE instance.
>
>2-  When deque rate calculation is used to calculate queue delay, here I
>am completely confused about what does the text means and hope you
>clearly it:  
>
>"we recommend one PIE instance using the overall queue length divided by
>the overall deque rate. Then the overall PIE->drop_prob_ is modified
>using each individual queue divided by the maximum individual queue
>length: PIE-
>>drop_prob_(i)=queue_.byte_length(i)/max(queue_.byte_length(i))."
>	
>For new drop_prob calculation, how can drop_prob_ be just a division of
>queue lengths?
>	drop_prob_(i)=queue_.byte_length(i)/max(queue_.byte_length(i))


>>>>>>>>>>>>>>>>>>>>>>>>>RP: Let¹s say there are two flows that are queued into
two sfq queues. One flow is an elephant flow and one flow is mice flow. Total
latency is caused by the elephant flow. The above equation makes sure that the
mice flow (whose queue length is zero, or very small amount) won¹t be dropped.
Besides, since it is mice flow, it would be hard to measure its departure rate
as the queue would never build up.qdelay




>
>
>4) In page 20, the code of enque function:
>
>>//called on each packet arrival
>>  enque(Packet packet) {
>>       if (PIE->drop_prob_ == 0 && current_qdelay < QDELAY_REF
>>           && PIE->qdelay_old_ < QDELAY_REF) {
>>           PIE->burst_allowance_ = MAX_BURST;
>>       }
>
>According to the description and the code in section 4.4 (Burst
>Tolerance), the condition should be
>       if (PIE->drop_prob_ == 0 && current_qdelay < QDELAY_REF/2
>           && PIE->qdelay_old_ < QDELAY_REF/2) {


>>>>>>>>>>>>>>>>>>>>>>>>>>Fixed...



>
>5) In pages 23 and 24,
>
>>       //If the queue has been idle for a while, turn off PIE
>>       //reset counters when accessing the queue after some idle
>>       //period if PIE was active before
>>       if ( PIE->drop_prob_ == 0 && PIE->qdelay_old_ == 0
>>            && queue_.byte_length() == 0) {
>>            PIE->active_ = INACTIVE;
>
>According to section 5.3 (Turning PIE on and off), the condition of
>deactivating PIE should be:
>
>if (PIE->drop_prob_ == 0 and current_qdelay < QDELAY_REF/2 and
>      PIE->qdelay_old_ < QDELAY_REF/2) {


>>>>>>>>>>>>>>>>>>>>>>>>>>RP: Fixed.




>
>
>6) In page 26,
> 
>> if ( PIE->dq_count_ >= DQ_THRESHOLD) {
>And
>> if (queue_.byte_length() >= DQ_THRESHOLD &&
>
>Just to make the conditions consistence with section 5.2 (Departure Rate
>Estimation),  use '>' instead of '>=' or change the condition in the code
>of section 5.2 to use '>=' instead of '>'.
>


>>>>>>>>>>>>>>>>>>>>>>>>>>RP: Fixed, changed in Section 5.2

>
>Regards,
>Rasool Al-Saadi
>
>> -----Original Message-----
>> From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of internet-
>> drafts@ietf.org
>> Sent: Wednesday, 2 March 2016 7:16 AM
>> To: i-d-announce@ietf.org
>> Cc: aqm@ietf.org
>> Subject: [aqm] I-D Action: draft-ietf-aqm-pie-05.txt
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>>directories.
>> This draft is a work item of the Active Queue Management and Packet
>> Scheduling of the IETF.
>> 
>>         Title           : PIE: A Lightweight Control Scheme To Address
>>the Bufferbloat
>> Problem
>>         Authors         : Rong Pan
>>                           Preethi Natarajan
>>                           Fred Baker
>> 	Filename        : draft-ietf-aqm-pie-05.txt
>> 	Pages           : 26
>> 	Date            : 2016-03-01
>> 
>> Abstract:
>>    Bufferbloat is a phenomenon where excess buffers in the network cause
>>    high latency and jitter. As more and more interactive applications
>>    (e.g. voice over IP, real time video streaming and financial
>>    transactions) run in the Internet, high latency and jitter degrade
>>    application performance. There is a pressing need to design
>>    intelligent queue management schemes that can control latency and
>>    jitter; and hence provide desirable quality of service to users.
>> 
>>    This document presents a lightweight active queue management design,
>>    called PIE (Proportional Integral controller Enhanced), that can
>>    effectively control the average queueing latency to a target value.
>>    Simulation results, theoretical analysis and Linux testbed results
>>    have shown that PIE can ensure low latency and achieve high link
>>    utilization under various congestion situations. The design does not
>>    require per-packet timestamp, so it incurs very small overhead and is
>>    simple enough to implement in both hardware and software.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-aqm-pie/
>> 
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-aqm-pie-05
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-pie-05
>> 
>> 
>> 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/
>> 
>> _______________________________________________
>> aqm mailing list
>> aqm@ietf.org
>> https://www.ietf.org/mailman/listinfo/aqm
>
>_______________________________________________
>aqm mailing list
>aqm@ietf.org
>https://www.ietf.org/mailman/listinfo/aqm