* Better naming/logging for send side bwe
* Check BWE congestion state before doing optimal allocation.
It is possible that BWE declares congestion, but the estimated bandwidth
may still be enough to accommodate all tracks. So, stream allocator
would still not in DEFICIENT state. On a new track allocation, it will
get optimal allocation although BWE is in congested state.
Take BWE congestion state into consideration before doing any track
allocation.
* get congestion state from BWE rather than caching it in stream allocator
* get states from update
* log contributing groups only when they are small in number
* get oldest group always
* notify only when estimate is dropping
* require stronger CTR down trend
* maintain min/max group
* relax thresholds to declare congestion a bit
* Thottle the publisher data channel sending when subscriber is slow
Avoid the publisher overwhelm the sfu data channel buffer when
the subscriber has lower receive bitrates. It will drop message
if the subscriber is considered too slow to block the entire room.
* Enable nack in mediaengine and disable it in transceiver as need
pion doesn't support per transciver codec configuration, so the nack of this session will be disabled
forever once it is first disabled by a transceiver.
https://github.com/pion/webrtc/pull/2972
There are cases where the probe result has enough headroom to up
allocate all deficient tracks. Mainly happens after a loss scenario
where the estimate is actually still high.
After boosting once, there was a check for the track to hit the desired
layer before boosting again. But, that is not really necessary. Can
boost target and forwarder should resolve to the latest target.
Removing that check in the forwarder.
Also, adding a gratuitous boost check in stream allocator periodic ping
when deficient to look for opportunities to boost.
* Don't wait rtp packet to fire track
Create track from sdp instead of first rtp packet,
it is consistent with the browser behavior and
will accelerate the track publication.
* fix test
* WIP
* no worker
* fixes
* use congested packet groups
* oldest group
* markers
* WIP
* WIP
* WIP
* WIP
* WIP
* clean up
* fmt
* consolidate
* store last packet only for bwe extension cases
* Try up-allocation on neutral trend.
Some probes end up with neutral trend due to getting much estimates of
same value. It is okay to try up-allocating in those cases. Otherwise,
the stream allocator some times gets stuck and does not up-allocate at
all as all probes end up neutral.
Changing the name of the signal to `NotCongesting` to signify it is
either neutral or clearing.
* wait 5 RTT for probe to finalize
* trend detector object encoder
Reverting back to pre-refactor behaviour. Was trying to avoid doing
special treatment when in probe, but REMB values are hard to predict
and the NACKs as well.
So, freeze updates when congesting in probe till the probe is done.
Otherwise, further changes while probe is finalising sometimes causes an
invalid signal and tracks are not up allocated.
* Clean up remote BWE a bit.
- Had forgotten to start worker, fix that
- ensure correct type of channel observer (probe OR non-probe) based on
probe state.
- introduce congested hangover state to see better state transitions.
Does not really affect operation, but state transitions are clearer.
* prevent 0 ticker
* Simplify probe sleep calculations.
Splitting into buckets made it problematic around the boundaries and it
was ugly code too. Simplify and set up probes with sleep after each
probe to get the desired interval/rate.
* continue after pop
* Sender side snap shot clean up and logging.
Seeing cases of sender snap shot packet loss much higher the actual
packets some times. Tracking a bit more to understand that better.
- Rename variables to indicate what is coming from feed side clearly
- Fixed an issue with wrong init of feed side loss in snapshot
- Just use the loss from receiver report as it can go back (receiver
would subtract on receiving out-of-order packet).
- keep track sof reports in a snapshot (this is temporary for
debugging/understanding it better and will be removed later)
* remove check
* Log more details of RTP stats snap shots.
Seeing cases of loss more than 100%. Logging snap shots to understand it
better.
* log message
* use delta to update packets lost from RR
* remove cast
Cosmetic. While thinking through how to structure probing better,
noticing small things here and there. Cleaning up and making some small
PRs along the way.
* keep track of RTX bytes separately
* packet group
* Packet group of 50ms
* Minor refactoring
* rate calculator
* send bit rate
* WIP
* comment
* reduce packet infos size
* extended twcc seq num
* fix packet info
* WIP
* queuing delay
* refactor
* config
* callbacks
* fixes
* clean up
* remove debug file, fix rate calculation
* fmt
* fix probes
* format
* notes
* check loss
* tweak detection settings
* 24-bit wrap
* clean up a bit
* limit symbol list to number of packets
* fmt
* clean up
* lost
* fixes
* fmt
* rename
* fixes
* fmt
* use min/max
* hold on early warning of congestion
* make note about need for all optimal allocation on hold release
* estimate trend in congested state
* tweaks
* quantized
* fmt
* TrendDetector generics
* CTR trend
* tweaks
* config
* config
* comments
* clean up
* consistent naming
* pariticpant level setting
* log usage mode
* probing hacks
* WIP
* no lock
* packet group config
* ctr trend refactor
* cleanup and fixes
* format
* debug
* format
* move prober to ccutils
* clean up
* clean up
* Fix header size calculation in stats.
With pacer inserting some extensions, the header size used in stats
(and more impoetantly when probing for bandwidth estimation and
metering the bytes to control the probes) was incorrect. The size
was effectively was that of incoming extensions. It would have been
close enough though.
Anyhow, a bit of history
- initially was planning on packaging all the necessary fields into
pacer packet and pacer would callback after sending, but that was not
great for a couple of reasons
- had to send in a bunch of useless data (as far as pacer is
concerned) into pacer.
- callback every packet (this is not bad, just a function call which
happens in the foward path too, but had to lug around the above
data).
- in the forward path, there is a very edge case issue when calling stats update
after pacer.Enqueue() - details in https://github.com/livekit/livekit/pull/2085,
but that is a rare case.
Because of those reasons, the update was placed in the forward path
before enqueue, but did not notice the header size issue till now.
As a compromise, `pacer.Enqueue` returns the headerSize and payloadSize.
It uses a dummy header to calculate size. Real extension will be added
just before sending packet on the wire. pion/rtp replaces extension if
one is already present. So, the dummy would be replaced by the real one
before sending on the wire.
https://github.com/pion/rtp/blob/a21194ecfb5362261a0dc4af1f68e4a8944df345/packet.go#L398
This does introduce back the second rare edge case, but that is very
rare and even if it happens, not catastrophic.
* cleanup
* add extensions and dummy as well in downtrack to make pacer cleaner
cnderrauber