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

From: Naeem Khademi <[email-masked]>
Date: Fri, 6 Mar 2015 16:17:54 +0100

Hi all

Any comments on the newly submitted update as
draft-ietf-aqm-eval-guidelines-01 is welcomed. In the new version, we have
tried to address the issues brought up on the ML as well as the feedback we
received at the IETF-91 and have tried to incorporate them all. We have
also clarified several issues in the text making it more straightforward
and less ambiguous with regards to the "guidelines" and "scenarios". We
would like to have this document discussed on the ML preferably before the
9th March cut-off date as well as during the period prior to IETF-92.

Cheers,
Authors

---

From: "LAUTENSCHLAEGER, Wolfram (Wolfram)" <[email-masked]>
Date: Mon, 9 Mar 2015 13:32:55 +0000

Hi,

Bi-directional traffic is mentioned in section 3.1 Topology and 4.5 Traffic Mix, but not further detailed.

I suggest to add at least one scenario in section 4.5, where both directions are congested at the same time, e.g. two or more counter propagating bulk TCP transfers. Only in this scenario the returning ACK packets undergo a reasonable queuing delay (and jitter) from the opposite direction queue. If I'm right, Dave Taht repeatedly mentioned that scenario as critical. And he is right, I tried it out.

Wolfram

Von: aqm [mailto:[email-masked]] Im Auftrag von Naeem Khademi
Gesendet: Freitag, 6. März 2015 16:18
An: [email-masked]
Betreff: [aqm] Comments on draft-ietf-aqm-eval-guidelines-01?

Hi all

Any comments on the newly submitted update as draft-ietf-aqm-eval-guidelines-01 is welcomed. In the new version, we have tried to address the issues brought up on the ML as well as the feedback we received at the IETF-91 and have tried to incorporate them all. We have also clarified several issues in the text making it more straightforward and less ambiguous with regards to the "guidelines" and "scenarios". We would like to have this document discussed on the ML preferably before the 9th March cut-off date as well as during the period prior to IETF-92.

Cheers,
Authors

---

From: Nicolas Kuhn <[email-masked]>
Date: Tue, 10 Mar 2015 07:47:14 +0100

Hi, 

> On 09 Mar 2015, at 14:32, LAUTENSCHLAEGER, Wolfram (Wolfram) <[email-masked]> wrote:
> 
> Hi,
>  

You are right, we should have included this scenario a while ago. 
Because it is too late now for submitting an updated version of the draft, what follows it what will be presented at IETF92. 
In the 02 version of the draft, we will update the ToC of the document as follows:

"
  4.  Various TCP variants  . . . . . . . . . . . . . . . . . . . .  12
     4.1.  TCP-friendly Sender . . . . . . . . . . . . . . . . . . .  12
     4.2.  Aggressive Transport Sender . . . . . . . . . . . . . . .  13
     4.3.  Unresponsive Transport Sender . . . . . . . . . . . . . .  13
     4.4.  TCP initial congestion window . . . . . . . . . . . . . .  14
     4.5.  Traffic Mix . . . . . . . . . . . . . . . . . . . . . . .  14
“
will become 

"
   4.  Various TCP variants  . . . . . . . . . . . . . . . . . . . .  12
     4.1.  TCP-friendly sender . . . . . . . . . . . . . . . . . . .  12
     4.2.  Aggressive transport sender . . . . . . . . . . . . . . .  13
     4.3.  Unresponsive transport sender . . . . . . . . . . . . . .  13
     4.4.  TCP initial congestion window . . . . . . . . . . . . . .  14
…
   8.  Various traffic profiles  . . . . . . . . . . . . . . . . . .  20
     8.1.  Traffic Mix . . . . . . . . . . . . . . . . . . . . . . .  20
     8.2.  Bi-directional traffic  . . . . . . . . . . . . . . . . .  21
“

And the content of the section 8 will be: 

“
8.  Various traffic profiles

   This section provides guidelines to assess the performance of an AQM
   proposal for various traffic profiles such as traffic with different
   applications or bi-directional traffic.

8.1.  Traffic Mix

   This scenario helps to evaluate how an AQM scheme reacts to a traffic
   mix consisting of different applications such as:

   o  Bulk TCP transfer

   o  Web traffic

   o  VoIP

   o  Constant Bit Rate (CBR) UDP traffic

   o  Adaptive video streaming

   Various trafic mixes can be considered.  These guidelines RECOMMEND
   to examine at least the following example: 1 bi-directionnal VoIP; 6
   Webs; 1 CBR; 1 Adaptive Video; 5 bulk TCP.  Any other combinations
   could be considered and should be carefully documented.

   For each scenario, the graph described in Section 2.6 could be
   generated for each class of traffic.  In addition, other metrics such
   as end-to-end latency, jitter and flow completion time MUST be
   reported.

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.
"

Regards, 

Nicolas Kuhn

> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm

---

From: "LOCHIN Emmanuel" <[email-masked]>
Date: Tue, 10 Mar 2015 08:28:59 +0100

Hi all,

Reading section "12.4 Packet sizes and congestion notification", I'm wondering whether this should also apply to pure ack traffic?

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
Tel +33 5 61 33 91 85 - Fax (+33) 5 61 33 83 30
Plan d'accès/Access map -  Page personnelle

---

From: Nicolas Kuhn <[email-masked]>
Date: Tue, 10 Mar 2015 08:52:14 +0100

Hi,

> On 10 Mar 2015, at 08:28, LOCHIN Emmanuel <[email-masked]> wrote:
> 
> Hi all,
> 

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/ ], 
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

> 10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE - http://www.isae-supaero.fr <http://www.isae-supaero.fr/>
> Plan d'accès/Access map <http://plan.univ-toulouse.fr/#783> - Page personnelle <http://personnel.isae.fr/emmanuel-lochin>

---

From: "LOCHIN Emmanuel" <[email-masked]>
Date: Tue, 10 Mar 2015 11:01:29 +0100

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.

Regards

EK

Le Mardi 10 Mars 2015 08:52 CET, Nicolas Kuhn <[email-masked]> a écrit:
  Hi, On 10 Mar 2015, at 08:28, LOCHIN Emmanuel <[email-masked]> 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/ ], 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

--
  
Emmanuel LOCHIN
Professeur ISAE

---

From: Nicolas Kuhn <[email-masked]>
Date: Wed, 11 Mar 2015 16:55:17 +0100

> On 10 Mar 2015, at 11:01, LOCHIN Emmanuel <[email-masked]> wrote:
> 

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.

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

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

Kind regards, 

Nicolas KUHN

> Regards
> 
> EK
> 
> 
> Le Mardi 10 Mars 2015 08:52 CET, Nicolas Kuhn <[email-masked] <mailto:[email-masked]>> a écrit:
>  
>> 
>>  
> Hi,
>  
>> On 10 Mar 2015, at 08:28, LOCHIN Emmanuel <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> Hi all,
>> 
> [ https://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ <https://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/> ], 
> where it is said: