[R-C] Suggesting a "Flow State Exchange" (FSE)

[Michael Welzl]

Hi Radhika,

Cool to hear that you like it!

I agree that it could become complex as we add more features - obvious  
questions include: for how long should information in the FSE be  
regarded as "valid"? What's the point of figuring out that there are 3  
other flows traversing the same bottleneck, when 2 of them will  
terminate in the next 10ms? - leading to: can we include information  
about how long flows will be active, or prescribe that flows are  
assumed to have a certain (expected) minimum duration when they store  
their information in the FSE?

The FSE would also have to be active in terms of maintaining its own  
state, at least if we assume soft state (which might make sense, given  
that applications accessing it might crash).

But before going into such details I'd like to hear more opinions...  
maybe some folks are totally opposed to it?
(although I'd argue that this is, by design, a pill that should be  
easy to swallow  ;-)   )

Cheers,
Michael


On Jul 25, 2012, at 3:46 PM, Roy, Radhika R CIV (US) wrote:

> Hi, Michael:
>
> I see it as a good approach because FSE is a passive entity.
>
> However, the activities that need to be analyzed from congestion  
> indication point of view although seems to be a simple one as we see  
> now, I have seen it becomes more complex as more features are  
> included.
>
> So, it is worthwhile to discuss all aspects of FSE which are needed  
> of RTP flows and let us examine whether FSE still remains simple and  
> easy to implement despite all other congestion (active) schemes are  
> available.
>
> Best regards,
> Radhika
>
> -----Original Message-----
> From: rtp-congestion-bounces at alvestrand.no [mailto:rtp-congestion-bounces at alvestrand.no 
> ] On Behalf Of Michael Welzl
> Sent: Wednesday, July 25, 2012 9:13 AM
> To: rtp-congestion at alvestrand.no
> Subject: [R-C] Suggesting a "Flow State Exchange" (FSE)
>
> Hi all,
>
> This is a "chair hat taken off and thrown into a corner" message -  
> very much my personal thoughts, and I'm very curious what you all  
> think:
>
> Starting point: there is a desire to have priorities between flows,  
> e.g. in rtcweb, but maybe also between other RTP streams.
>
> I have been arguing that the right way to do this is to have only a  
> single congestion control entity, and then realize fairness among  
> the flows as a result of scheduling data across them. I still  
> believe that this is the right way to do it (and - Randell please  
> correct me if I'm wrong - it seems that this is the approach already  
> pursued by Mozilla). This thinking led me to propose my all-over- 
> SCTP idea.
>
> Now, I don't see how such a thing could be standardized, especially  
> if we don't want to limit ourselves to rtcweb only. HOWEVER: it is  
> clear that flows will need information about other flows - such as:  
> what is their priority? How many are there, that we can assume to  
> traverse the same bottleneck (e.g. because they share the same UDP 5- 
> tuple)? What is their current sending rate?
>
> Without having agreed on how to exchange such information, I think  
> it will be hard to implement the above fairness solution or any other
> good(*) solution in a standard-conformant way. Therefore I propose  
> that we should standardize what I think is the simplest possible,  
> necessary element: a "Flow State Exchange" (FSE).
>
> An FSE is a *passive* entity on a host that receives congestion-  
> control-relevant information from RTP flows and provides that  
> information upon request. It resides on a host, and if we define it  
> in the right way it probably doesn't matter at which layer: one  
> could have an FSE inside the browser, and optionally have the  
> browser talk to an additional system-wide FSE in the kernel. Note  
> that this is not the Congestion Manager (RFC3124): the CM was an  
> *active* entity, much more complicated to realize, and much closer  
> to the "single congestion control instance" idea described above.
>
> With an FSE, a single congestion control instance could be realized as
> follows:
> RTP flows => update the FSE.
> CC. instance => reads information from the FSE, then controls the  
> sending rate per RTP flow and schedules data across the flows.
>
> Alternative implementation (not as good, but simpler, and just to  
> show the flexibility): RTP 1 uses its own CC, RTP 2 uses its own CC,  
> but they feed the priority they got "from above" into the FSE and  
> read each other's priority and total sending rate from there, to  
> adapt their increase/decrease behavior accordingly, leading to the  
> desired total behavior on the wire.
>
> It's not hard to imagine that this could be extended in many ways -  
> e.g. the SCTP data channel could access the FSE to also incorporate  
> priorities there...  and implementations could provide information  
> about which flows share a bottleneck based on measurements, not only  
> because of the UDP 5-tuple, without requiring to standardize any of  
> that. But the FSE itself would have to be there.
>
> What do you all think?
>
> Cheers,
> Michael
>
> -----------------------
>
> (*) The only prioritization solution that I can think of which would  
> not require something along the lines of an FSE would be prioritized  
> congestion control, i.e. giving weights to something like MulTCP,
> MulTFRC ...   which means that the fairness you get is essentially
> what flows produce, as the result of fighting it out on the  
> bottleneck. This will create more delay than any FSE-based solution,  
> working against one main goal of all of us here: reduced delay.
>
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion