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

[Christoph Paasch <[e-mail]>]

Hello Bjorn,



> On Dec 21, 2023, at 2:40 AM, Bjørn Ivar Teigen <[e-mail]> 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=[e-mail] <mailto:[e-mail]>> 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
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/ippm
> 
> 
> --
> Bjørn Ivar Teigen, Ph.D.
> Head of Research
> [phone] | [e-mail] <mailto:[e-mail]> | www.domos.ai <http://www.domos.ai/>
>  <https://www.understandinglatency.com/>
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm