Subject: [ippm] Estimating IP layer capacity in draft-morton-ippm-capacity-metric-method

From: Nieminen Klaus <[email-masked]>
Date: Tue, 19 Nov 2019 05:33:17 +0000

Hi,

I have one question on how much this metric restricts the measurement setup and e.g. can WebTransport be used in the measurement? As I understand this, if we are running the measurement at the application layer, we can measure application layer (e.g. HTTP/3) payload. This again means that we can only estimate the IP layer capacity as we do not have full information about the header sizes or potential retransmissions. I think we can estimate this with a certain error margin, but I was not sure if this is fine according to the metric.

I have not studied this much further, but started to think this question when I read the part 5.3.  Metric Definitions that talks a case where the packet size is known and of fixed size, but is this really the case? Should there be more flexibility to also be able to estimate the IP layer capacity from the application layer measurement results? I think this should be clarified.

And if we think this should be possible, at least I think it would be useful to add how this estimation can be done to the metric itself as the  target is to harmonize the specified metric and this is not specified, it may lead discrepancies between implementations. 

Any thoughts on this?

Best, Klaus

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 21 Nov 2019 07:37:05 +0000

Hi Klaus,

Thanks for your method and implementation questions.
We've discussed this in-person, and a short
summary follows below.

Al

> -----Original Message-----
> From: ippm [mailto:[email-masked]] On Behalf Of Nieminen Klaus
> Sent: Tuesday, November 19, 2019 12:33 AM
> To: [email-masked]
> Subject: [ippm] Estimating IP layer capacity in draft-morton-ippm-
> capacity-metric-method
> 
> Hi,
> 
> I have one question on how much this metric restricts the measurement
> setup and e.g. can WebTransport be used in the measurement? As I
> understand this, if we are running the measurement at the application
> layer, we can measure application layer (e.g. HTTP/3) payload. This again
> means that we can only estimate the IP layer capacity as we do not have
> full information about the header sizes or potential retransmissions. I
> think we can estimate this with a certain error margin, but I was not sure
> if this is fine according to the metric.
[acm] 
It should be possible to obtain information from the host OS about the 
lower layers in use, such as v4 or v6, ETH or WiFi or Cellular LTE/5G.
But there may be cases where some work is necessary to pass system info
to the measurement application.

We need to use UDP for transport: error distributions with TCP are seen 
to be time and technology dependent. TCP's congestion-awareness based on
packet loss, window sizes, reordering, and duplicate packets make for an
underestimate, which is often significant and highly variable. Many test
results illustrating the error have been shared.

> 
> I have not studied this much further, but started to think this question
> when I read the part 5.3.  Metric Definitions that talks a case where the
> packet size is known and of fixed size, but is this really the case?
> Should there be more flexibility to also be able to estimate the IP layer
> capacity from the application layer measurement results? I think this
> should be clarified.
[acm] 
It's very much easier to do the layer conversions when we use UDP, with
fixed and known sizes, but there are cases where we might want to 
allow a portion of two sizes.  
@@@@ update text with this idea.
> 
> And if we think this should be possible, at least I think it would be
> useful to add how this estimation can be done to the metric itself as the
> target is to harmonize the specified metric and this is not specified, it
> may lead discrepancies between implementations.
[acm] 

@@@@ Layer conversion:
The authors have lots of details on these calculations, having done
many of them during lab and field tests and tool development.

> 
> Any thoughts on this?
> 
> Best, Klaus
> 
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=CkKxfs26ipBr8nSSaJUfs8BBGtBje
> wOBqsS1FBX9cJk&s=xST_c50cCPP49eav2yMJWG-osdzvmay-ZZ02x6M5X8s&e=