From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A31CC3B29D for ; Fri, 7 Jun 2024 10:07:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1717769239; x=1718374039; i=moeller0@gmx.de; bh=10kAyqOQm+tTH2K8hrN2XaSgKppIbr11egsPInL/gTg=; h=X-UI-Sender-Class:Content-Type:Mime-Version:Subject:From: In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id: References:To:cc:content-transfer-encoding:content-type:date:from: message-id:mime-version:reply-to:subject:to; b=OA9GJpe8vcPY/nk9zBaJBdxfiHNBZFrmoOu6na9/WV7PxIvbIRH4vpBE4zMCG2it 5ZEvoJGFsIMpm8W4JiiTvxCfxI0648aJS1lsKM6wEMA34tbqrHBjuHE2l7K2Og0dW kPj+M5o4PDmaxzf0lX0Q8z8PZo+DGtukmLS2kw47TuslMg2N2WJRcSB+btYgFbzNV In9bp2XlC49n8Kjv+HMAZXYKg9eNa0FBRmKaM9MBO57fiU+AiezA/60cJWiMklUV0 JKeYUMs5by0ft3mAQM6u4ufooMLCM+Hl3oB1tIWQCTEuLVTiE5I8lGG80DlFqUfM1 BdwJ8vMgMKeHq37MhQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MORAa-1s5C010oRC-00OL65; Fri, 07 Jun 2024 16:07:19 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) From: Sebastian Moeller In-Reply-To: Date: Fri, 7 Jun 2024 16:07:08 +0200 Cc: "starlink@lists.bufferbloat.net" Content-Transfer-Encoding: quoted-printable Message-Id: <61FA5621-4E64-4CB3-81BA-04D568939E68@gmx.de> References: <64FC2A3B-D512-4270-9285-C5AD69BBE40E@gmx.de> To: Colin_Higbie X-Mailer: Apple Mail (2.3774.600.62) X-Provags-ID: V03:K1:PsLEw+5+p6i4+XFiNpHkmiSOZElTDPuNgAwdTstkPaCUSAFQcpJ yiWJZDNrSBqB91Ziz67GxlDfeF0zIF1OTHYarN9lEAzHaUYo2/vXGVgNNMqIFX+58CpNxZa dn5Oo2/a3yVP1R3vXOg6Zcwjwoxa0bj86y0QLLEFj26/0IWw3oPL68/1pYzTBY3M1QzMtSl 6RA4oYTlCY65D2cjYZ2gA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:uwDXWrB98Zo=;iWYK12IBPSFsd21g5Nk8SdO4vdW eIozy9tHDdk+PDQdFZfBx2k9GCCX94gp2c1ZQRb4JH7brqSXXY3w9PAc5/WEOM7FhV7wEIIRe 3hZT+hMycsOz76UEhwCoyejYLk9GwoJ4vqlkNqi7TbSKTgvDKq3IsDpYtFgnGLczr9KY9sh8V TUvgu1p/+q9ymVUtKBz1JcNDTtmo3XoIZRbKBFf0uG75vVPPstFZjo3tjI38ah7PYficehjzm Bu5BNb55wChzqfh/7PfVO+7TwLp8jVNglupSR1clhS1ENponyBKauvMif0SwToEI0O5lvZ0Ye G0/nwTtPj1aH5Gm4VKS2ANLEtOPIGrNsiUhowax7hX+P8B/mLG4eUnL/YD0UaSK+lcSDSyDQ8 Zkv9LG3Hy7hkiaZCkHRO8X4yRnOk2tqAuY1GQqaWc5t24rC0yExIs9m/DjBZzUnj/W+DCbx3k wRaHKCcXiqjyZI9UIW0//GaiJ/WVHt0eVt0NGtIo/zcj36blif250yWOP1DmvMNlihDe1n99B OfJf8W7iYD6QJ83V/7DhQltpIKH/5N/MA7YRohSVAtX6dYfQNSF+HjTixZGi+bsSr40Vr4b3O rBcZ46yXBCNjjH8F622HMShdwhc9Rl7kSTuU/md9UWYT/HwnoZ62K8K1gWB3irNxA5bR5SkZf oDGoBmZO9zaBbEM/gt8fuHjTz7BvMQ34o1VA049KqjgWoMj0I3BIwUIXvlYmIdWT3YOEWOREy PUEv/rqXBsFUXlS2cEU/M79og43CeANBuQgnfgXsXw5/LK13waixuUKordCVgIIxoFOgzHVCT hiRLA+DZcez07mPGauLhvyTcUivXdhk+73NWKwZRdiYlA= Subject: Re: [Starlink] 300ms Telecommunication Latency and FTL Communication X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2024 14:07:24 -0000 Hi Colin, Thank you very much, also for the paper and analysis you sent after = this. > On 6. Jun 2024, at 15:43, Colin_Higbie wrote: >=20 > Sebastion, I was not providing any knowledge or data on acceptable = latency for video calling. That is not my area of expertise (closest = facet of my business merely involves web site responsiveness and start = time for playing audio after buffering, both of which are much less = sensitive to latency). I can state that, as a user, I would find 150ms = measured ISP latency high, not intolerable, but noticeable - [SM] I agree, and there is the rub, unlike capacity where we often see = hard limits like a VoIP call takes ~100Kbps, if link capacity is = sufficiently smaller than 100 Kbps VoIP will not work at all (so there = will be hard qualitative thresholds), with latency we often see slow = degradation of quality... if e.g. VoIP works well at 100ms, it likely = will still be virtually identical at 101ms and still reasonably similar = at say 150ms... much harder to turn that into a convincing threshold... > video conferencing is more sensitive to latency than pure voice (in my = personal opinion, no study I've read on this specifically), because we = watch people's faces for reactions to what we say as we're speaking. [SM] I am happy to believe you on this, but ti turn this into something = useful for my purpose I will need to find something published, = preferably peer reviewed. But thanks to the pointer which should help in = my search. > If there is a noticeable lag there, it disrupts the conversation. On = the other hand, the same lag in a pure voice discussion, which is = inherently less synchronous, would not be noticeable. [SM] Not sure I fully agree here, assuming video and audio arrive both = with the same delay I would guess both suffer similarly from the = delay... my gut feeling is as long as natural speech sequence stays = intact, that is no unintended collisions due to both speaking at the = same time, audio-only and audio-video should both be sort of OK... >=20 > In my prior post, I was using the 150/300 ms figure you provided and = saying that IF that's the max acceptable figure for network latency, = THEN that's already a problem to only hit that as the ISP because each = participant also adds their distance and network delays. For those that = are just as quick, that may be fine. However, assuming there's some form = of bell curve distribution on latency, many of these will be longer, and = some much longer than what your ISP provides to their customers. = Therefore, to ensure a satisfactory experience with the majority of = prospective video call participants on other networks, the ISP would = need to provide a sufficiently low latency to accommodate these = differences. Otherwise, a significant portion of the calls would be of = poor quality. Obviously, they can't make up for a participant whose own = latency exceeds 300ms, but they should not be the cause of poor = communication with someone at 160ms latency. But that's just reasoning = around your numbers, not data. [SM] I am looking at the studies underlaying ITU-114 delay quality = assessments, but I think that is a long shot in convincing the = regulsator, these numbers are deeply entrenched by know, so I likely = would need a more recebt study that conclusively shows that these = numbers are way too high... >=20 > That said, here are some studies I found that may be helpful: >=20 > This one includes the 300ms round-trip time, but puts at the extreme = outer range of acceptability: > "Defining 'seamlessly connected': user perceptions of operation = latency in cross-device interaction" > = https://www.sciencedirect.com/science/article/abs/pii/S1071581923000770 >=20 > "What Are Good Latency & Ping Speeds?" > https://www.pingplotter.com/wisdom/article/is-my-connection-good/ >=20 > A Cisco discussion that supports the 300ms round trip time: > "Acceptable Jitter, Latency and Packet Loss for Audio and Video on a = WebEx Meeting" > = https://community.cisco.com/t5/webex-meetings-and-webex-app/acceptable-jit= ter-latency-and-packet-loss-for-audio-and-video-on/m-p/4301454 >=20 >=20 > These are behind pay walls or require academic credentials, so don't = know if they are good or not, nor what conclusions they reach - they = could even be the source of the 150/300ms figure, but I agree with you = that seems high:=20 >=20 > "A Study of the Effects of Network Latency on Visual Task Performance = in Video Conferencing" > https://dl.acm.org/doi/10.1145/3491101.3519678 > = https://www.academia.edu/98061737/A_Study_of_the_Effects_of_Network_Latenc= y_on_Visual_Task_Performance_in_Video_Conferencing >=20 > "Effect of latency on social presence in traditional video conference = and VR conference: a comparative study" > https://ieeexplore.ieee.org/document/10402741 >=20 > "Determination of the latency effects on surgical performance and the = acceptable latency levels in telesurgery using the dV-Trainer((r)) = simulator" > https://pubmed.ncbi.nlm.nih.gov/24671353/ [SM] Thanks a lot, I will go look these up. Regards Sebastian >=20 >=20 > -----Original Message----- > From: Sebastian Moeller =20 > Sent: Thursday, June 6, 2024 3:22 AM > To: Colin_Higbie > Cc: starlink@lists.bufferbloat.net > Subject: Re: 300ms Telecommunication Latency and FTL Communication >=20 > Hi Colin, >=20 >=20 >=20 >> On 5. Jun 2024, at 19:58, Colin_Higbie wrote: >>=20 >> Sebastian, >>=20 >> At 300ms RTT, that would mean the starting point for any = communications are already at the threshold of unacceptability. >=20 > [SM] Not according to the ITU (114) > mouth-ear delay in ms (so OWDs) > 0-200ms: users very satisfied > 200-275ms: users satisfied > 275-375ms: some users dissatisfied > 375-600: many users dissatisfied > 600-...: nearly all users dissatisfied >=20 > So even 150ms OWD still falls within the very satisfied range if the = remaining delay is not to large... And even if er string two of these = users together, we end up with worst case >300ms delay, but that sill = only gets us into the "some users dissatisfied" which the regulator = might find an acceptable trade-off in the context of guaranteed internet = access parameters (where the idea is the 150ms OWD or 300ms RTT is not = the target, but the threshold for being acceptable). >=20 > My gut feeling is these ranges are not actually measured in a way they = are now interpreted (e.g. when testing transatlantic call delays users = likely already had an expectancy of longer delay and simply judges these = calls against a different yard stick). BUT unless I can demonstrate that = the original studies resulting in these numbers are terminally flawed = there is little chance that I can convince our regulator to take my word = vor voice delays over the word of the ITU... so I need different, = preferably newer data and focus on probably remote desktop usage as a = relative novel use case without much encrusted ideas about acceptable = latency... >=20 >=20 >> I would think the strongest argument is that's at best a passable = latency in absolutely perfect conditions, which never exist. "Pleasant" = communication latency is sub-100ms, adding additional travel time to the = actual servers involved and processing at each end, the ISP needs to do = significantly better than that target to provide some margin for those = other sources of latency, many controlled by fundamental physics sending = the signal over distance. >=20 > [SM] Personally I agree, yet I am not sure picking a fight over the = VoIP numbers is going to be productive, as I have considerably less = clout with the regulator than the ITU... >=20 > Regards > Sebastian