Hi,
> On 09 Mar 2015, at 14:32, LAUTENSCHLAEGER, Wolfram (Wolfram)
> <[email protected]> wrote:
>
> 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.
>
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
> Wolfram
>
>
> Von: aqm [mailto:[email protected]] Im Auftrag von Naeem Khademi
> Gesendet: Freitag, 6. März 2015 16:18
> An: [email protected]
> 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
>
>
> _______________________________________________
> aqm mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/aqm
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
