Re: [ippm] WGLC for draft-ietf-ippm-responsiveness

Thanks Christoph, that sounds good to me.

Cheers,
Bjørn

On Wed, 17 Jan 2024 at 19:45, Christoph Paasch <cpaasch@apple.com> wrote:

> Hello Bjorn,
>
>
>
> On Dec 21, 2023, at 2:40 AM, Bjørn Ivar Teigen <bjorn@domos.no> wrote:
>
> Hello IPPM,
>
>
> I've read draft-ietf-ippm-responsiveness-03. The draft is well-written and easy to read in my opinion. I consider the contribution novel and useful.
>
>
> Please find my comments and questions inline below:
>
>
>
> IP Performance Measurement                                     C. Paasch
> Internet-Draft                                                  R. Meyer
> Intended status: Standards Track                             S. Cheshire
> Expires: 22 April 2024                                        Apple Inc.
>                                                               W. Hawkins
>                                                 University of Cincinnati
>                                                          20 October 2023
>
>                 Responsiveness under Working Conditions
>                    draft-ietf-ippm-responsiveness-03
> Abstract
>
> .....
>
>
> 4.1.1.  Single-flow vs multi-flow
>
>
> .....
>
> One of the configuration parameters for the test is an upper bound on the
> number of parallel load-generating connections. We recommend a default
> value for this parameter of 16.
>
>
> Question: What is the rationale for choosing 16 as the upper bound?
>
>
> No specific rationale. It just needs to be reasonably high to allow full
> link utilization without exceeding client/server resources.
>
> .....
>
> 7. Responsiveness Test Server Discovery ..... Consider this example
> scenario: A user has a cable modem service offering 100 Mb/s download
> speed, connected via gigabit Ethernet to one or more Wi-Fi access points in
> their home, which then offer service to Wi-Fi client devices at different
> rates depending on distance, interference from other traffic, etc. By
> having the cable modem itself host a Responsiveness Test Server instance,
> the user can then run a test between the cable modem and their computer or
> smartphone, to help isolate whether bufferbloat they are experiencing is
> occurring in equipment inside the home (like their Wi-Fi access points) or
> somewhere outside the home.
>
>
> Comment: It might be useful to add some reflections about how measurements to different points can be compared.
>
> For arguments sake, let's say we measure towards two hypothetical servers and get RPM to an ISP-hosted server of 500, and RPM to the cable modem of 3000.
>
> How can those values be compared or otherwise reasoned about?
>
>
> Good point. I think that would fit very well in Section 5.2:
>
> Beyond the difference in the latency of the load-generating connections
> and the separate connections another element can provide additional
> information. Namely testing against different servers located in different
> places along the path will allow to some extent to separate the network’s
> path in different segments. For example, if the cable modem and a further
> away ISP server are hosting responsiveness measurement endpoints, some
> localization of the issue can be done. If the RPM to the cable modem is
> very high, it means that the network segment from the client endpoint to
> the cable modem does not have responsiveness issues, thus allowing the user
> to conclude that possible responsiveness issues are beyond the cable modem.
> It must be noted though that due to the high level approach to the testing
> (including HTTP), a low responsiveness to the cable modem does not
> necessarily mean that the network between client and cable modem is the
> problem (as outlined in the above previous paragraphs).
>
>
> Does this sound good to you?
>
>
> Thanks,
> Christoph
>
>
> Best regards,
>
> Bjørn Ivar Teigen
>
>
> On Tue, 5 Dec 2023 at 19:10, Marcus Ihlar <marcus.ihlar=
> 40ericsson.com@dmarc.ietf.org> wrote:
>
>>
>>
>> Hello IPPM,
>>
>>
>>
>> This email starts a Working Group Last Call for " Responsiveness under
>> Working Conditions”, draft-ietf-ippm-responsiveness.
>>
>>
>>
>> https://datatracker.ietf.org/doc/draft-ietf-ippm-responsiveness/
>>
>> https://www.ietf.org/archive/id/draft-ietf-ippm-responsiveness-03.html
>>
>>
>>
>> Please review the document and send your comments in response to this
>> email, along with whether you think the document is ready to progress.
>>
>>
>>
>> Please send your reviews and feedback by *Friday, **December* *22*.
>>
>>
>>
>> BR,
>>
>> Marcus & Tommy
>>
>>
>> _______________________________________________
>> ippm mailing list
>> ippm@ietf.org
>> https://www.ietf.org/mailman/listinfo/ippm
>>
>
>
> --
> Bjørn Ivar Teigen, Ph.D.
> Head of Research
> +47 47335952 | bjorn@domos.ai | www.domos.ai
> [image: https://www.understandinglatency.com/]
> <https://www.understandinglatency.com/>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>
>
>

-- 
Bjørn Ivar Teigen, Ph.D.
Head of Research
+47 47335952 | bjorn@domos.ai | www.domos.ai
[image: https://www.understandinglatency.com/]
<https://www.understandinglatency.com/>