Re: [aqm] Comments on draft-ietf-aqm-eval-guidelines-01?

Nicolas Kuhn <nicolas.kuhn@telecom-bretagne.eu> Wed, 11 March 2015 15:55 UTC

Return-Path: <nicolas.kuhn@telecom-bretagne.eu>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDE41ACD29 for <aqm@ietfa.amsl.com>; Wed, 11 Mar 2015 08:55:37 -0700 (PDT)
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 hXMrzbsRlTdq for <aqm@ietfa.amsl.com>; Wed, 11 Mar 2015 08:55:30 -0700 (PDT)
Received: from zproxy210.enst-bretagne.fr (zproxy210.enst-bretagne.fr [192.108.117.8]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8BA1AC529 for <aqm@ietf.org>; Wed, 11 Mar 2015 08:55:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTP id CE3C123286F; Wed, 11 Mar 2015 16:55:20 +0100 (CET)
Received: from zproxy210.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy210.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id BGFN8lYohlM3; Wed, 11 Mar 2015 16:55:19 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTP id 6BF5C232893; Wed, 11 Mar 2015 16:55:19 +0100 (CET)
X-Virus-Scanned: amavisd-new at zproxy210.enst-bretagne.fr
Received: from zproxy210.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy210.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vqCBrjp0yKTR; Wed, 11 Mar 2015 16:55:19 +0100 (CET)
Received: from [IPv6:2001:660:7301:3728:91c:b628:41e8:482f] (passerelle-interne.enst-bretagne.fr [192.108.117.210]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTPSA id 2C74A23286F; Wed, 11 Mar 2015 16:55:19 +0100 (CET)
Content-Type: multipart/alternative; boundary="Apple-Mail=_0F21F95C-1317-4C32-B7EA-8020E2295F6D"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Nicolas Kuhn <nicolas.kuhn@telecom-bretagne.eu>
In-Reply-To: <5351-54fec100-6b-e685050@67600570>
Date: Wed, 11 Mar 2015 16:55:17 +0100
Message-Id: <48E66DFB-943B-419E-BC51-D6784E9F9634@telecom-bretagne.eu>
References: <5351-54fec100-6b-e685050@67600570>
To: LOCHIN Emmanuel <Emmanuel.LOCHIN@isae.fr>
X-Mailer: Apple Mail (2.1990.1)
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/0jC2WEUjvzNtA7EGPadl6fTyhSU>
Cc: "aqm@ietf.org" <aqm@ietf.org>, Naeem Khademi <naeem.khademi@gmail.com>
Subject: Re: [aqm] Comments on draft-ietf-aqm-eval-guidelines-01?
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Wed, 11 Mar 2015 15:55:37 -0000

> On 10 Mar 2015, at 11:01, LOCHIN Emmanuel <Emmanuel.LOCHIN@isae.fr> wrote:
> 
> So it means that a correct evaluation MUST takes into account the proportion of data traffic from signalling traffic (pure ACK for instance) otherwise performance measurements might be biaised.
> 

In the current version (01) of the draft, the traffic goes in one direction only. 
So a correct evaluation MUST indeed take into account the fact that only data traffic
goes through the buffered ruled by an AQM. 

In the updated version (02) (which is not on-line because we just missed the cut-off to 
upload the version that assesses Wolfram’s comments), we will add a specific 
“both directions” case, where signalling and data packets are mixed.

------------------------------------------------------------------------------------------------------- 

8.2.  Bi-directional traffic

   Control packets such as DNS requests/responses, TCP SYNs/ACKs are
   small, but their loss can severely impact the application
   performance.  The scenario proposed in this section will help in
   assessing whether the introduction of an AQM scheme increases the
   loss probability of these important packets.

   For this scenario, traffic MUST be generated in both downlink and
   uplink, such as defined in Section 3.1.  These guidelines RECOMMEND
   to consider a mild congestion level and the traffic presented in
   section Section 7.2.2 in both directions.  In this case, the metrics
   reported MUST be the same as in section Section 7.2 for each
   direction.

   The traffic mix presented in section Section 8.1 MAY also be
   generated in both direction.

------------------------------------------------------------------------------------------------------- 

Kind regards, 

Nicolas KUHN

> Regards
> 
> EK
> 
> 
> Le Mardi 10 Mars 2015 08:52 CET, Nicolas Kuhn <nicolas.kuhn@telecom-bretagne.eu <mailto:nicolas.kuhn@telecom-bretagne.eu>> a écrit:
>  
>> 
>>  
> Hi,
>  
>> On 10 Mar 2015, at 08:28, LOCHIN Emmanuel <Emmanuel.LOCHIN@isae.fr <mailto:Emmanuel.LOCHIN@isae.fr>> wrote:
>>  
>> Hi all,
>> 
>> Reading section "12.4 Packet sizes and congestion notification", I'm wondering whether this should also apply to pure ack traffic?
>>  
>  
> For this specific section, for the sake of consistency between the IETF documents, 
> we refer to the “draft-ietf-aqm-recommendation“ document 
> [ https://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ <https://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/> ], 
> where it is said:
> 1- in section "4.4 - AQM algorithms SHOULD respond to measured congestion, not application profiles."
> “
> Procedures for selecting packets to mark/drop
>    SHOULD observe the actual or projected time that a packet is in a
>    queue (bytes at a rate being an analog to time).  When an AQM
>    algorithm decides whether to drop (or mark) a packet, it is
>    RECOMMENDED that the size of the particular packet should not be
>    taken into account [RFC7141].
> " 
> 2- in section "4.5.  AQM algorithms SHOULD NOT be dependent on specific transport protocol behaviours"
> “
> AQM methods should be opaque to the choice of transport and application.
> "
>  
> IMHO, these two points infer that this would be applied for pure ack traffic as well. 
> If changes need to be done on that aspect, it should be on the “draft-ietf-aqm-recommendation“ document.
>  
> Whatever happens, the “characterisation guidelines" document should be consistent with the “recommendation document”, 
> and now that you mention this section, I am not sure that a discussion on the packet sizes is needed in the “characterisation guidelines” document.  
> What do you think ?
>  
> Kind regards, 
>  
> Nicolas
>  
>> 
>> EL
>> 
>> --
>>  
>>  	
>> Emmanuel LOCHIN
>> Professeur ISAE
>> ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace
>> 10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE - http://www.isae-supaero.fr <http://www.isae-supaero.fr/>
>> Tel +33 5 61 33 91 85 - Fax (+33) 5 61 33 83 30
>> Plan d'accès/Access map <http://plan.univ-toulouse.fr/#783> - Page personnelle <http://personnel.isae.fr/emmanuel-lochin>
> 
> 
> --
>  
>  	
> Emmanuel LOCHIN
> Professeur ISAE
> ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace
> 10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE - http://www.isae-supaero.fr <http://www.isae-supaero.fr/>
> Tel +33 5 61 33 91 85 - Fax (+33) 5 61 33 83 30
> Plan d'accès/Access map <http://plan.univ-toulouse.fr/#783> - Page personnelle <http://personnel.isae.fr/emmanuel-lochin>