Re: [aqm] Benoit Claise's Discuss on draft-ietf-aqm-eval-guidelines-11: (with DISCUSS and COMMENT)

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Tue, 14 June 2016 07:20 UTC

Return-Path: <ietf@kuehlewind.net>
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 B470C12DB36 for <aqm@ietfa.amsl.com>; Tue, 14 Jun 2016 00:20:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.328
X-Spam-Level:
X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 0ixoUwvYUcnl for <aqm@ietfa.amsl.com>; Tue, 14 Jun 2016 00:20:03 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB73C12DA06 for <aqm@ietf.org>; Tue, 14 Jun 2016 00:20:02 -0700 (PDT)
Received: (qmail 5800 invoked from network); 14 Jun 2016 09:13:16 +0200
Received: from p5dec201e.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.32.30) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 14 Jun 2016 09:13:16 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <fe21f1c1-cc5b-4b2a-ce65-43bf7dcef28c@cisco.com>
Date: Tue, 14 Jun 2016 09:13:14 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <F817D4C8-044D-4DE8-81AE-9D4259EA56AE@kuehlewind.net>
References: <20160519093824.17314.65212.idtracker@ietfa.amsl.com> <8D2CEA6F-BC90-4606-B737-1F5837178C1A@kuehlewind.net> <DEC82FD2-9F80-465A-AA16-C13C4766B54C@kuehlewind.net> <4AF73AA205019A4C8A1DDD32C034631D458D677B27@NJFPSRVEXG0.research.att.com> <2E5B5988-B119-44F6-BA82-F59F817948FB@kuehlewind.net> <4AF73AA205019A4C8A1DDD32C034631D458D677B29@NJFPSRVEXG0.research.att.com> <5CA63370-E84C-4C84-92A8-9C298B2CD0C3@kuehlewind.net> <4AF73AA205019A4C8A1DDD32C034631D458D677B2D@NJFPSRVEXG0.research.att.com> <82287fc6-473a-617c-757c-69bb2e7ce17a@cisco.com> <575A8DB2.3040702@kuehlewind.net> <ff2b5cc0-22be-7898-39f4-cd163b8f358b@cisco.com> <575ABD37.6090706@kuehlewind.net> <4AF73AA205019A4C8A1DDD32C034631D458D677DD2@NJFPSRVEXG0.research.att.com> <575AF0F9.6060801@tik.ee.ethz.ch> <4AF73AA205019A4C8A1DDD32C034631D458D677DDF@NJFPSRVEXG0.research.att.com> <BFE08369-0903-4712-86C6-765B82B89E10@tik.ee.ethz.ch> <4AF73AA205019A4C8A1DDD32C034631D458D677FCC@NJFPSRVEXG0.research.att.com> <fe21f1c1-cc5b-4b2 a-ce65-43bf7dcef28c@cisco.com>
To: Benoit Claise <bclaise@cisco.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/aqm/jADPRtPKbx7fekQ1SYNX27nhITU>
Cc: "MORTON, ALFRED C (AL)" <acmorton@att.com>, "wes@mti-systems.com" <wes@mti-systems.com>, "aqm-chairs@ietf.org" <aqm-chairs@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-aqm-eval-guidelines@ietf.org" <draft-ietf-aqm-eval-guidelines@ietf.org>, "Schulthess Nicolas (F&W)" <nicolas.schulthess@sl.ethz.ch>, "aqm@ietf.org" <aqm@ietf.org>
Subject: Re: [aqm] Benoit Claise's Discuss on draft-ietf-aqm-eval-guidelines-11: (with DISCUSS and COMMENT)
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: Tue, 14 Jun 2016 07:20:06 -0000

Yes, already contacted the authors!

Thanks all!

> Am 14.06.2016 um 08:42 schrieb Benoit Claise <bclaise@cisco.com>:
> 
> 
>>> -----Original Message-----
>>> From: Mirja Kühlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch]
>>> Sent: Monday, June 13, 2016 3:41 PM
>> ...
>>> Hi Al,
>>> 
>>> I believe, we agree here. However, I’m not really sure what needs to be
>>> changed/added in the draft now. The only concrete item I have is
>>> replacing "application-level“ by "transport-layer payload“. Anything
>>> else?
>>> 
>>> Mirja
>> [ACM]
>> Thanks, that would resolve the biggest ambiguity for me.
>> Like I said last week, I think we're done (with that change).
> Thank you Al and Mirja.
> I'll clear the DISCUSS on that basis, trusting the AD that the addition will be introduced.
> 
> Regards, Benoit
>> 
>> Al
>> 
>>> 
>>>> Am 10.06.2016 um 19:16 schrieb MORTON, ALFRED C (AL)
>>> <acmorton@att.com>:
>>>> more below, thanks for the clarifications, Mirja!
>>>> Al
>>>> 
>>>>> -----Original Message-----
>>>>> From: Mirja Kühlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch]
>>>>> Sent: Friday, June 10, 2016 12:55 PM
>>>>> To: MORTON, ALFRED C (AL); Mirja Kühlewind; Benoit Claise
>>>>> Cc: wes@mti-systems.com; aqm-chairs@ietf.org; The IESG; draft-ietf-
>>> aqm-
>>>>> eval-guidelines@ietf.org; Schulthess Nicolas (F&W); aqm@ietf.org
>>>>> Subject: Re: [aqm] Benoit Claise's Discuss on draft-ietf-aqm-eval-
>>>>> guidelines-11: (with DISCUSS and COMMENT)
>>>>> 
>>>>> Hi Al,
>>>>> 
>>>>> see below.
>>>>> 
>>>>> On 10.06.2016 18:41, MORTON, ALFRED C (AL) wrote:
>>>>>> Hi, see below,
>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Mirja Kühlewind [mailto:ietf@kuehlewind.net]
>>>>>>> Sent: Friday, June 10, 2016 9:15 AM
>>>>>>> To: Benoit Claise; MORTON, ALFRED C (AL)
>>>>>>> Cc: wes@mti-systems.com; aqm-chairs@ietf.org; The IESG; draft-ietf-
>>>>> aqm-
>>>>>>> eval-guidelines@ietf.org; Schulthess Nicolas (F&W); aqm@ietf.org
>>>>>>> Subject: Re: [aqm] Benoit Claise's Discuss on draft-ietf-aqm-eval-
>>>>>>> guidelines-11: (with DISCUSS and COMMENT)
>>>>>>> 
>>>>>>> Benoit,
>>>>>>> 
>>>>>>> waiting for Al. But in the mean time see below.
>>>>>>> 
>>>>>>> On 10.06.2016 11:57, Benoit Claise wrote:
>>>>>>>> Al, assuming that someone would like to register this metric in a
>>>>>>> registry
>>>>>>>> (RFC6390), are they any grey areas in the performance metric
>>>>>>> definitions in
>>>>>>>> the draft?
>>>>>>>>  From what I understand, a point such this one (from Al) is:
>>>>>>>> 
>>>>>>>>     Because we are using Goodput, G, I take as given that there
>>>>>>>>     must be a protocol with retransmission capability.
>>>>>>>>     Otherwise, further simplification is possible (with dummy
>>>>>>> traffic).
>>>>>>> 
>>>>>>> Not really if you have not retransmission, simply your
>>>>>>> goodout=throughput.
>>>>>>> Don't see a problem here.
>>>>>> [ACM]
>>>>>> Although Goodput == Throughput for UDP, you can make a
>>>>>> simpler measurement, you don't have to check for uniqueness.
>>>>> 
>>>>> That's the view from someone measuring in the network. But if you do
>>>>> simulations or have a controlled testbed, the easiest things is to
>>>>> measure in
>>>>> the application (and you automatically get the right thing). As we
>>> don't
>>>>> know
>>>>> what exactly people do in the end, I think it is right to leave this
>>>>> open
>>>>> (and leave it as simple as possible in the description text).
>>>> [ACM]
>>>> Ok, but what layer of the application?  The raw media stream(s)?
>>>> Or everything in the TCP/UDP payload?
>>>> 
>>>> In lab benchmarking, it's sometimes about measuring at
>>>> link speed x number of ports, so every operation makes a difference!
>>>> 
>>>>> 
>>>>>>>>     But yes, Fs and G need to be reported on payload
>>>>>>>>     at the same layer, so the protocol layer chosen is
>>>>>>>>     an input parameter for this metric.
>>>>>>> Yes, it need to be the same layer for all your tests; but the goal
>>> is
>>>>>>> not be
>>>>>>> compatible with other tests. So it's your decision. It's guidance
>>> how
>>>>>>> you
>>>>>>> would test AQMs to decide if you want to deploy them in the future
>>>>> (or
>>>>>>> to
>>>>>>> show that your AQM has benefits compared to other AQMs such that
>>>>> another
>>>>>>> guy
>>>>>>> might deploy this in future).
>>>>>> [ACM]
>>>>>> 
>>>>>> The current text mentions the "application layer" but needs to add
>>> the
>>>>> note
>>>>>> that the layer chosen needs to be specified/included in with the
>>>>> results, so that
>>>>>> someone reading results later will know what was tested.
>>>>> There actually is now a sentence saying:
>>>>> 
>>>>> "Where flow size is the size of the application-level flow in bits
>>> and
>>>>> goodput is the application-level transfer time (described in
>>>>> Section 2.5)."
>>>>> 
>>>>> Is this sufficient?
>>>> [ACM]
>>>> 
>>>> I don't mean to prolong this, but I haven't been clear:
>>>> The term "application-level" is ambiguous, it could be
>>>> RTP, or some other container layer, or one of the MPEG layers,
>>>> or the raw media/program stream (with our without meta data).
>>>> 
>>>> If by saying "application-level", the transport-layer payload
>>>> is meant, I suggest to say that.
>>>> 
>>>> are we there yet? I know I am :-), it's 19:15 down the road in Geneva!
>>>> Al
>>>> 
>>>>> Mirja
>>>>> 
>>>>> 
>>>>>> Al
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> 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
> 
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm