Hi,


1-      Regarding the CIR/PIR

IMHO this is out of the scope of the characterization guidelines. However, if you think that we should introduce more information on the MPLS/IP router architectures please let us know. The only problem being that we want to be quite generic and do not want to focus on specific architectures.


2-      Regarding buffer sizes

Since buffer sizing is not the only problem of evaluating AQMs, we have looked for RFC clearly stipulating how the "adequate" buffer size can be found. As said in RFC7597:
"
The optimum buffer size is a function of
   operational requirements and should generally be sized to be
   sufficient to buffer the largest normal traffic burst that is
   expected.  This size depends on the amount and burstiness of traffic
   arriving at the queue and the rate at which traffic leaves the queue.
"

In the characterization draft, the recommendation on the buffer size is not a "MUST".
If you think that we should more clearly say that the size of the buffer MAY be set to the BDP, let us know.
In its current state, it has been voluntary that the draft does not impose any buffer size.

Cheers,

Nicolas

De : Scharf, Michael (Michael) [mailto:michael.scharf@alcatel-lucent.com]
Envoyé : vendredi 2 octobre 2015 19:06
À : Kuhn Nicolas; Lane Wigley (lwigley); tcpm@ietf.org
Objet : RE: TCP evolution impact on router buffers

Regarding Section 7 in [2], I am surprised that a potential impact of CIR/PIR is not mentioned. Unfortunately, I have only a very limited understanding of MPLS/IP router architectures, but the way bursts hit an AQM could IMHO depend on that.

As [2] is mentioned, one question related to the discussion below. From [2]:

3.2.  Buffer size

   The size of the buffers should be carefully chosen, and is to be set
   to the bandwidth-delay product; the bandwidth being the bottleneck
   capacity and the delay the largest RTT in the considered network.

This means of the order of 10GB of buffer size for a 400G router interface, right? Wouldn't it make sense to relax the statement "... and is to be set..." a bit?

Michael


From: Kuhn Nicolas [mailto:Nicolas.Kuhn@cnes.fr]
Sent: Wednesday, September 30, 2015 6:41 PM
To: Lane Wigley (lwigley); Scharf, Michael (Michael); tcpm@ietf.org<mailto:tcpm@ietf.org>
Subject: RE: TCP evolution impact on router buffers

Hi,

In [1], the authors evaluate the performance of CUBIC in small buffer regime. However, they use the Linux kernel version 2.6.18 (where the IW was 3 and not 10). Also, for any tests on CUBIC, small buffers and IW3/10, you may be interested in looking at the scenario "7.  Burst absorption" of the AQM Characterization Guidelines of the AQM WG [2]. Concerning TCP pacing, there is an on-going document on a pacing solution in the slow-start that you may want to have a look and comment [3].

I hope this helps,
Cheers,

Nicolas

[1] Jain, S.; Raina, G., "An experimental evaluation of CUBIC TCP in a small buffer regime," in Communications (NCC), 2011 National Conference on , vol., no., pp.1-5, 28-30 Jan. 2011
doi: 10.1109/NCC.2011.5734779
URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5734779&isnumber=5734693
[2] https://tools.ietf.org/html/draft-ietf-aqm-eval-guidelines-08
[3] https://tools.ietf.org/html/draft-sallantin-tcpm-initial-spreading-01

De : tcpm [mailto:tcpm-bounces@ietf.org] De la part de Lane Wigley (lwigley)
Envoyé : mercredi 30 septembre 2015 15:10
À : Scharf, Michael (Michael); tcpm@ietf.org<mailto:tcpm@ietf.org>
Objet : Re: [tcpm] TCP evolution impact on router buffers

This paper from 2008 shows no drops with a 5 msec buffer on a heavily-congested core link. Low levels of drops start to show up around 2.5 msec. This was conducted at Level 3 to test the BDP / sqrt # flows proposal from Stanford.

Experimental Study of Router Buffer Sizing - Neda Beheshti, Yashar Ganjali, Monia Ghobadi, Nick McKeown, and Geoff Salmon

They also explored TCP pacing as a way to further reduce buffers. I'm trying to assess if CUBIC results in some pacing effect by decoupling the window growth from acks.

- Lane


From: Scharf, Michael (Michael) [mailto:michael.scharf@alcatel-lucent.com]
Sent: Tuesday, September 29, 2015 6:56 PM
To: Lane Wigley (lwigley); tcpm@ietf.org<mailto:tcpm@ietf.org>
Subject: RE: TCP evolution impact on router buffers

This question may also be in scope of the AQM WG, and perhaps ICCRG, but since the communities overlap, I avoid cross-posting...

Unfortunately, I don't have any recent pointer or own data. But I am aware of examples for router buffer dimensioning based on tests with a single TCP connection, using Reno. In those examples, the dimension of the buffers and possibly other related parameters (two-color/three-color meters/policiers, WRED slopes, H-QoS, etc.) are configured to achieve full "line" speed for a single TCP connection. As to be expected, this typically comes down to the old BDP rule of thumb. But it is rather obvious that a single bulk data Reno connection is not necessarily a realistic workload these days. So, the test methodology can be one relevant aspect of the dimensioning problem.

I believe that a modern TCP stack with a high-speed congestion control such as CUBIC will typically need less buffer than the outcome of this dimensioning method and the publications 10 years ago. As far as I know, most modern TCP stacks operate well over a very wide range of buffer sizes, and the buffers can be relatively small. To me, the key question is the latency-throughput tradeoff, and there may not be a one-fits-all answer to that one.

Personally, I'd also be interested in more recent pointers on router buffer dimensioning. I could even see some value in documenting dimensioning guidelines used in practice, if there was a way to generalize them.

Michael



From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Lane Wigley (lwigley)
Sent: Friday, September 25, 2015 5:41 PM
To: tcpm@ietf.org<mailto:tcpm@ietf.org>
Subject: [tcpm] TCP evolution impact on router buffers

I'm trying to track down some research or opinions on how the more recent TCP schemes impact router buffer needs. There are a number of publications from Stanford and Georgia Tech from about 10 years ago, and I'm trying to assess how changes to the algorithms (e.g. CUBIC) and parameters (initial congestion window) deployed since then may influence those findings in the direction of more or less buffering being needed.

I'd appreciate any input and pointers. Thanks.

- Lane