Moving BWE logic to the send client?

[pablo platt]

There is an issue aboutmoving BWE logic to the send client.
https://bugs.chromium.org/p/webrtc/issues/detail?id=4173

Does it mean that all the logic will be on the peer that sends the stream instead of the current implementation where the receiver calculates the bandwidth?

Is there a spec describing the process?

Will it still be called goog-remb?

How will you make the transition?

Thanks

[Stefan Holmer]

On Tue, Mar 22, 2016 at 9:29 PM pablo platt <pablo...@gmail.com> wrote:

There is an issue aboutmoving BWE logic to the send client.
https://bugs.chromium.org/p/webrtc/issues/detail?id=4173

Does it mean that all the logic will be on the peer that sends the stream instead of the current implementation where the receiver calculates the bandwidth?

Yes. Actually, today the logic is split between sender and receiver, where the sender calculates REMB based delay metrics, and the sender calculates the final bitrate based on the received REMB and the packet loss report received with RTCP.

The plan is to move the receive-side logic to the sender to make the receiver simpler.

 

Is there a spec describing the process? 

Will it still be called goog-remb?

How will you make the transition?

Are you referring to the process of moving the logic to the sender? We'll be introducing a new feedback format in Chrome called transport-cc in SDP. Take a look at https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions-01 if you are interested in the details. https://tools.ietf.org/html/draft-ietf-rmcat-gcc-01 describes how the BWE can be implemented on the send-side.

REMB and abs-send-time will still be around for now to ensure compatibility with old clients. REMB can also be useful after moving logic to the sender since the receiver may want to notify the sender about what bitrates it can handle.

 

Thanks

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CANdLC8V34oK_0TRbZfPAr8a6ruP5pMkhx%2BhtAJ7%3DxQyxgibWUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[pablo platt]

Thanks

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAEdus3%2BQaTp%3D1oxVx9NLbY9YOMWp5wY4n3DrrW10KPi%3DQ9UcsA%40mail.gmail.com.

[mparis]

Hello Stefan,
Which is the objective of moving the logic to the sender side?
This implies an overhead in the network due to the amount of RTCP packets needed.

[Stefan Holmer]

There are some reasons:

- Easier to roll out improvements if the logic is located on one side and the other side is kept dumb.

- Having the logic on the send-side means you know more about what has been sent. For instance, you know if the source is very bursty (screencasts) which can help us make better decisions.

Basically, we think we can do a better job if we have it all located at the sender. The overhead shouldn't be too bad in relation to a video stream.

/Stefan

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/2b897b22-20da-438c-b925-87d944ff9269%40googlegroups.com.

[mparis]

OK, thanks for the explanation ;).