From: Jack Haverty <jack@3kitty.org>
To: nnagain@lists.bufferbloat.net
Subject: Re: [NNagain] CFP march 1 - network measurement conference
Date: Wed, 6 Dec 2023 17:54:23 -0800 [thread overview]
Message-ID: <6d87504d-294b-457d-8eb8-ff52e26364e7@3kitty.org> (raw)
In-Reply-To: <CAJbqEYCkt=qmeeXqYN0NJG_Diu1+px4qHY=zTyHLGTa8MU4f3w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4544 bytes --]
IMHO, characterizing performance warrants more measurements, e.g.,:
- amount (bytes, datagrams) presumed lost and re-transmitted by the sender
- amount (bytes, datagrams) discarded at the receiver because they were
already received
- amount (bytes, datagrams) discarded at the receiver because they
arrived too late to be useful
With such data, it would be possible to measure things like "useful
throughput", i.e., the data successfully delivered from source to
destination which was actually useful for the associated user's application.
Some useful measurements were included in RFC 1213, e.g., in the "TCP"
and "UDP" sections, such as number of retransmissions. These
measurements likely require instrumentation in the sending and receiving
computers, where the TCP and similar algorithms operate.
Measurements also may depend strongly on the particular computer type
and operating system. Measurements obtained from various "probe"
sources and destinations, such as a "test host", provide only part of a
"comprehensive measurement". A complete characterization of the
performance achieved would include measurement data from the users' host
computers attached to the Internet, as they are doing whatever the user
does.
I don't recall if the SNMP MIB definitions were ever extended to include
metrics appropriate for uses such as VOIP, video conferencing, remote
operation, et al. Those are the kinds of uses which are most sensitive
to latency and variance in latency and throughput, and probably most
interesting to measure.
Jack Haverty
On 12/6/23 13:46, Sauli Kiviranta via Nnagain wrote:
> Thank you for sharing! This looks very promising!
>
> What would be a comprehensive measurement? Should cover all/most relevant areas?
>
> Payload Size: The size of data being transmitted.
> Event Rate: The frequency at which payloads are transmitted.
> Bitrate: The combination of rate and size transferred in a given test.
> Bandwidth: The data transfer capacity available on the test path.
> Throughput: The data transfer capability achieved on the test path.
> Transfer Efficiency: The ratio of useful payload data to the overhead data.
> Round-Trip Time (RTT): The ping delay time to the target server and back.
> RTT Jitter: The variation in the delay of round-trip time.
> Latency: The transmission delay time to the target server and back.
> Latency Jitter: The variation in delay of latency.
> Bit Error Rate: The corrupted bits as a percentage of the total
> transmitted data.
> Packet Loss: The percentage of packets lost that needed to be recovered.
> Energy Efficiency: The amount of energy consumed to achieve the test result.
>
> Did I overlook something? Too many dimensions to cover? Obviously some
> of those are derived, so not part of the whole set as such.
>
> Maybe then next would be to have different profiles where any of those
> parameters may vary over the test run. e.g. profiles that model
> congested base stations for mobile data. Different use case specific
> payload profiles e.g. gop for video transfer?
>
> Best regards,
> Sauli
>
>
> On 12/6/23, Dave Taht via Nnagain<nnagain@lists.bufferbloat.net> wrote:
>> This CFP looks pretty good to me:https://tma.ifip.org/2024/call-for-papers/
>>
>> Because:
>>
>> ¨To further encourage the results’ faithfulness and avoid publication
>> bias, the conference will particularly encourage negative results
>> revealed by novel measurement methods or vantage points. All regular
>> papers are hence encouraged to discuss the limitations of the
>> presented approaches and also mention which experiments did not work.
>> Additionally, TMA will also be open to accepting papers that
>> exclusively deal with negative results, especially when new
>> measurement methods or perspectives offer insight into the limitations
>> and challenges of network measurement in practice. Negative results
>> will be evaluated based on their impact (e.g. revealed in realistic
>> production networks) as well as the novelty of the vantage points
>> (e.g. scarce data source) or measurement techniques that revealed
>> them."
>>
>>
>> --
>> :( My old R&D campus is up for sale:https://tinyurl.com/yurtlab
>> Dave Täht CSO, LibreQos
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
>>
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
[-- Attachment #2: Type: text/html, Size: 5735 bytes --]
next prev parent reply other threads:[~2023-12-07 1:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-06 20:00 Dave Taht
2023-12-06 21:46 ` Sauli Kiviranta
2023-12-07 1:54 ` Jack Haverty [this message]
2023-12-07 2:22 ` Bill Woodcock
2023-12-07 14:16 ` [NNagain] [Bloat] " Kathleen Nichols
2023-12-08 6:03 ` [NNagain] " rjmcmahon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/nnagain.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6d87504d-294b-457d-8eb8-ff52e26364e7@3kitty.org \
--to=jack@3kitty.org \
--cc=nnagain@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox