Re: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01

["MORTON JR., AL" <[e-mail]>]

Hi Can,

Thanks for joining the discussion here, and for sharing your review with good ideas!

I’ll reply to each major point and suggestion below, [acm], and work with Len to see how we might add these features to the protocol.

Al

From: can desem <[e-mail]>
Sent: Thursday, October 21, 2021 3:29 AM
To: MORTON JR., AL <[e-mail]>
Cc: IETF IPPM WG <[e-mail]>
Subject: Re: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01

Hi Al, IPPM group,

I believe this will potentially be a really useful tool for measuring speeds, especially if we can incorporate it in network terminating devices such as customer gateways etc.
[acm]
Thanks!
We have had some success on this front, with customer premises equipment and small/inexpensive hosts. The running code has an option to help with older hardware, clocks that are slow by today’s standards, etc.

With regards the various options for the modes of operation, I think encrypting the payload will add additional cpu load without adding much benefit even though it may be valuable to defeat compression on links.
[acm]
Agreed, there is a tension between the security benefits and the ability of some network terminating devices to operate at full line rate. The simple approach of encrypting everything might reduce the universe of hardware support of measurements at 1 Gbps, for example.

Instead, having an option to randomize the payload may be less process intensive and achieve the same goal.
[acm]
Yes, that seems like a good option to have available when link compression is present. Thanks!  We could have several options in addition to pseudo-random payload content. I’ll add this as a To Do in the next draft.

Another suggestion that would be extremely useful, if this measurement tool were to be employed in a gateway like device, would be to take into consideration the existing traffic that may be present while running such a test. For example, monitoring the total traffic (which could be as simple as counting the bytes on a WAN interface on a gateway) as the test is run and including this as part of the measurement process would result in more accurate measurements of the line speed. This could be added as an option in the protocol which can be used when required in the described scenario.
[acm]
Yes, ideally the Maximum IP-Layer Capacity measurement would be made without competing traffic, having a way to count the competing traffic goes a long way to explaining measurement results when additional traffic is present. We still need to fill the pipe to measure the max, and normal applications don’t tend to do that. You and Len and I have been running some tests to investigate the feasibility of this feature – so far so good...  This is also on the To Do list.

Regards,
Can Desem
[acm]
Again, many thanks, Can!