Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
From: Sebastian Moeller <>
To: "Dave Täht" <>
Cc:, bloat <>,
	Rpm <>
Subject: [Galene] Re: [Rpm] very good article on webrtc bandwidth estimation
Date: Thu, 11 Jan 2024 20:26:17 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Dave,

> On Jan 11, 2024, at 14:53, Dave Taht via Rpm <> wrote:
> This was quite excellent, and did go into a delay based controller a bit.

	Yes, excellent article. I noted that the GCC draft contained this though:

The loss-based controller SHOULD run every time feedback from the
receiver is received.

   o  If 2-10% of the packets have been lost since the previous report
      from the receiver, the sender available bandwidth estimate
      As_hat(i) will be kept unchanged.

   o  If more than 10% of the packets have been lost a new estimate is
      calculated as As_hat(i) = As_hat(i-1)(1-0.5p), where p is the loss

   o  As long as less than 2% of the packets have been lost As_hat(i)
      will be increased as As_hat(i) = 1.05(As_hat(i-1))

   The loss-based estimate As_hat is compared with the delay-based
   estimate A_hat.  The actual sending rate is set as the minimum
   between As_hat and A_hat.

   We motivate the packet loss thresholds by noting that if the
   transmission channel has a small amount of packet loss due to over-
   use, that amount will soon increase if the sender does not adjust his
   bitrate.  Therefore we will soon enough reach above the 10% threshold
   and adjust As_hat(i).  However, if the packet loss ratio does not
   increase, the losses are probably not related to self-inflicted
   congestion and therefore we should not react on them.

Without even a hint of source where in the world 10% random (non-congestive) packet loss is "normal". (The justification given for the 10% would just works as badly for any other number < 100%...)
Just having had ~0.8% random loss on a link, I am unhappy to report that single flow tcp throughput was visibly affected (as expected from the Mathis equation).

Taking 2% packet loss as an indicator that one should increase the sending rate, IMHO should be backed by data, and preferably tons of it... as should the recommendation to simply soldier on with loss in the range of 2-10%....  I am not saying there might not be a rational argument to be made for those values, but that draft certainly did not make those arguments...

Side question: when I do MTRs to DNS servers I typically get 0% random packet loss, is there any study what level of non-congestive packet loss is typical for different parts of the internet?

> -- 
> 40 years of net history, a couple songs:
> Dave Täht CSO, LibreQos
> _______________________________________________
> Rpm mailing list

      reply	other threads:[~2024-01-11 19:26 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-11 13:53 [Galene] " Dave Taht
2024-01-11 19:26 ` Sebastian Moeller [this message]

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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='[Galene] Re: [Rpm] very good article on webrtc bandwidth estimation' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox