<html><head><style>body{font-family:CMU Sans Serif,Arial;font-size:14px}</style></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div style="font-family:CMU Sans Serif,Arial;font-size:14px; ">Hi Dave (Ricky, all),</div><div style="font-family:CMU Sans Serif,Arial;font-size:14px; "><br></div><div style="font-family:CMU Sans Serif,Arial;font-size:14px; ">Thanks for sharing the conference call. I am one of the TPC chair of the conference and we are really looking forward to cool submissions. So please get the idea mill going :)</div><div style="font-family:CMU Sans Serif,Arial;font-size:14px; "><br></div><div style="font-family:CMU Sans Serif,Arial;font-size:14px; ">[Putting my TPC chair hat aside] Application/CDN measurements would be cool! Most CDNs would probably map Starlink user to CDN server based on anycast but I am not sure if the server selection would be close to teh PoP or to the actual user location. Especially for EU users who are mapped to PoPs in other countries, would you get content of the PoP location country or of your own? What about offshore places that are connecting to GSes via long ISL chains (e.g. islands in south of Africa)?</div><div style="font-family:CMU Sans Serif,Arial;font-size:14px; "><br></div><div style="font-family:CMU Sans Serif,Arial;font-size:14px; ">Like many folks on this mailing list can already attest, performing real application workload experiments will be key here — performance under load is very different from ping/traceroutes based results that majority of publications in this space have relied on.</div><div style="font-family:CMU Sans Serif,Arial;font-size:14px; "><br></div> <div class="gmail_signature"><font face="CMUSansSerif"><span style="font-style: normal; font-size: 14px;">Thanks and Regards</span></font><div><font face="CMUSansSerif"><span style="font-style: normal; font-size: 14px;"><br></span></font></div><div><font face="CMUSansSerif"><span style="font-style: normal; font-size: 14px;">Nitinder Mohan</span></font></div><div><font face="CMUSansSerif"><span style="font-style: normal; font-size: 14px;">Technical University Munich (TUM)</span></font></div><div><a href="https://www.nitindermohan.com/" style="font-style: normal; font-size: 14px;"><font face="CMUSansSerif">https://www.nitindermohan.com/</font></a></div></div> <div class="airmail_ext_on" style="color:black"><br>From: <span style="color:black">Ricky Mok via Starlink</span> <a href="mailto:starlink@lists.bufferbloat.net"><starlink@lists.bufferbloat.net></a><br>Reply: <span style="color:black">Ricky Mok</span> <a href="mailto:cskpmok@caida.org"><cskpmok@caida.org></a><br>Date: <span style="color:black">7. December 2023 at 03:49:54</span><br>To: <span style="color:black">starlink@lists.bufferbloat.net</span> <a href="mailto:starlink@lists.bufferbloat.net"><starlink@lists.bufferbloat.net></a><br>Subject: <span style="color:black"> Re: [Starlink] [NNagain] CFP march 1 - network measurement conference <br></span></div><br> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>How about applications? youtube and netflix?<br><br>(TPC of this conference this year)<br><br>Ricky<br><br>On 12/6/23 18:22, Bill Woodcock via Starlink wrote:<br>><br>>> On Dec 6, 2023, at 22:46, Sauli Kiviranta via Nnagain <nnagain@lists.bufferbloat.net> wrote:<br>>> What would be a comprehensive measurement? Should cover all/most relevant areas?<br>> It’s easy to specify a suite of measurements which is too heavy to be easily implemented or supported on the network. Also, as you point out, many things can be derived from raw data, so don’t necessarily require additional specific measurements.<br>><br>>> Payload Size: The size of data being transmitted.<br>>> Event Rate: The frequency at which payloads are transmitted.<br>>> Bitrate: The combination of rate and size transferred in a given test.<br>>> Throughput: The data transfer capability achieved on the test path.<br>> All of that can probably be derived from sufficiently finely-grained TCP data. i.e. if you had a PCAP of a TCP flow that constituted the measurement, you’d be able to derive all of the above.<br>><br>>> Bandwidth: The data transfer capacity available on the test path.<br>> Presumably the goal of a TCP transaction measurement would be to enable this calculation.<br>><br>>> Transfer Efficiency: The ratio of useful payload data to the overhead data.<br>> This is a how-its-used rather than a property-of-the-network. If there are network-inherent overheads, they’re likely to be not directly visible to endpoints, only inferable, and might require external knowledge of the network. So, I’d put this out-of-scope.<br>><br>>> Round-Trip Time (RTT): The ping delay time to the target server and back.<br>>> RTT Jitter: The variation in the delay of round-trip time.<br>>> Latency: The transmission delay time to the target server and back.<br>>> Latency Jitter: The variation in delay of latency.<br>> RTT is measurable. If Latency is RTT minus processing delay on the remote end, I’m not sure it’s really measurable, per se, without the remote end being able to accurately clock itself, or an independent vantage point adjacent to the remote end. This is the old one-way-delay measurement problem in different guise, I think. Anyway, I think RTT is easy and necessary, and I think latency is difficult and probably an anchor not worth attaching to anything we want to see done in the near term. Latency jitter likewise.<br>><br>>> Bit Error Rate: The corrupted bits as a percentage of the total<br>>> transmitted data.<br>> This seems like it can be derived from a PCAP, but doesn’t really constitute an independent measurement.<br>><br>>> Packet Loss: The percentage of packets lost that needed to be recovered.<br>> Yep.<br>><br>>> Energy Efficiency: The amount of energy consumed to achieve the test result.<br>> Not measurable.<br>><br>>> Did I overlook something?<br>> Out-of-order delivery is the fourth classical quality criterion. There are folks who argue that it doesn’t matter anymore, and others who (more compellingly, to my mind) argue that it’s at least as relevant as ever.<br>><br>> Thus, for an actual measurement suite:<br>><br>> - A TCP transaction<br>><br>> …from which we can observe:<br>><br>> - Loss<br>> - RTT (which I’ll just call “Latency” because that’s what people have called it in the past)<br>> - out-of-order delivery<br>> - Jitter in the above three, if the transaction continues long enough<br>><br>> …and we can calculate:<br>><br>> - Goodput<br>><br>> In addition to these, I think it’s necessary to also associate a traceroute (and, if available and reliable, a reverse-path traceroute) in order that it be clear what was measured, and a timestamp, and a digital signature over the whole thing, so we can know who’s attesting to the measurement.<br>><br>> -Bill<br>><br>><br>> _______________________________________________<br>> Starlink mailing list<br>> Starlink@lists.bufferbloat.net<br>> https://lists.bufferbloat.net/listinfo/starlink<br>_______________________________________________<br>Starlink mailing list<br>Starlink@lists.bufferbloat.net<br>https://lists.bufferbloat.net/listinfo/starlink<br></div></div></span></blockquote></body></html>