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.
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@alvestrand.no [mailto:rtp-congestion-bounces@alvestrand.no] On Behalf Of Michael Welzl Sent: Wednesday, July 25, 2012 9:13 AM To: rtp-congestion@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
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@alvestrand.no [mailto:rtp-congestion-bounces@alvestrand.no ] On Behalf Of Michael Welzl Sent: Wednesday, July 25, 2012 9:13 AM To: rtp-congestion@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
Michael Welzl <michawe@ifi.uio.no> wrote:
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'm not positive that's exactly what's desired. We do desire that some flows be treated as more delay-critical than others; and IMHO that's not the same thing. It is perfectly legitimate to collect congestion indications for any and all traffic known to share the same path, but make data-rate reductions according to an application-layer algorithm (which could indeed be as simple as priority values for each sub-stream). So long as the overall data-rate is properly reduced, there's no question of "unfriendlyness".
... 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.
It _would_ need to receive congestion indications -- that seems to imply that the FSE belongs at transport layer.
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.
Your hands are waving... I suggest assuming the receiver's transport layer-stack(s) coordinate their congestion indications (by a function-call, for example) and receive instrution as to how much data-rate-reduction each of them should signal to the corresponding sender. (Yes, this does kind-of require greater precision in congestion feedback, but IMHO that's an unmitigated good-thing.)
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...
Yes, this seems to fit the SCTP paradigm nicely... -- John Leslie <john@jlc.net>
On Jul 25, 2012, at 6:51 PM, John Leslie wrote:
Michael Welzl <michawe@ifi.uio.no> wrote:
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'm not positive that's exactly what's desired.
For rtcweb, it is: it's requirement F34 in draft-ietf-rtcweb-use-cases- and-requirements
We do desire that some flows be treated as more delay-critical than others; and IMHO that's not the same thing.
I disagree with this separation of treatment. As soon as one flow is delay-critical, and as long as we cannot 100% know (we can hope, but IMO never know, within the soon-deployable- world...) that traffic isn't separated in the network, we must ensure that all congestion control is designed to such that delay is kept minimal. Otherwise, your own delay-critical flow will suffer from your own not-so-delay-critical flow... that makes no sense.
It is perfectly legitimate to collect congestion indications for any and all traffic known to share the same path, but make data-rate reductions according to an application-layer algorithm (which could indeed be as simple as priority values for each sub-stream). So long as the overall data-rate is properly reduced, there's no question of "unfriendlyness".
Yes, but that doesn't contradict my proposal.
... 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.
It _would_ need to receive congestion indications -- that seems to imply that the FSE belongs at transport layer
I agree, functionality-wise, and apologize for using the word "layer" here: I didn't mean this in the sense of network layers, but in a more physical sense - as in "where in the stack" or "where in the OS". I guess "level" would have been a better choice of words.
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.
Your hands are waving...
Oh yes! This is as sketchy as it gets, a totally new idea, shared with you straight away, to see what people think.
I suggest assuming the receiver's transport layer-stack(s) coordinate their congestion indications (by a function-call, for example) and receive instrution as to how much data-rate-reduction each of them should signal to the corresponding sender.
(Yes, this does kind-of require greater precision in congestion feedback, but IMHO that's an unmitigated good-thing.)
Okay, I was thinking sender-side here, but why not...
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...
Yes, this seems to fit the SCTP paradigm nicely...
-- John Leslie <john@jlc.net>
Cheers, Michael
Sounds a lot like RFC 3124? Lars On Jul 25, 2012, at 6:13, Michael Welzl <michawe@ifi.uio.no> wrote:
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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
nah. read the fine print - in the middle of my text, i was careful to insert a comment saying the following: ** 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. ** :-) It *really really* isn't the same. On Jul 25, 2012, at 8:07 PM, Eggert, Lars wrote:
Sounds a lot like RFC 3124?
Lars
On Jul 25, 2012, at 6:13, Michael Welzl <michawe@ifi.uio.no> wrote:
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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
I like where this is going, as long as we understand that any FSE is advisory information that may or may not be used by a given set of hosts. One underlying question is -- what actions will take place as a result of this information exchange? I do not think that this is a black and white question, and I think this is OK. As long as the behavior is "do no worse than if the FSE did not take place", we have not lost anything. In other words, if this information is made available to the hosts, and the hosts do not do anything with it - it is the exact same behavior as we have today. However, for a set of hosts that does have some knowledge of the relative flow priorities, those hosts now have the information to "do the right thing". There are many proprietary examples of hosts that do this today, but they are all silo-ed and do not interoperate. The best example I can think of is in the IPTV world. There are N hosts behind a constrained last mile. They know about each other's streams. They know about the bandwidth allocated to the video flows, and the system knows how to mark packets. The hosts simply co-operate to stay below the constrained link BW. However, we do need to be careful to stay away from mandating very heavy-weight methods. Old-style formal admission control methods are not desirable, IMHO. History has shown that such methods simply do get deployed into the areas in which we need to have flow visibility. As long as we think in terms of advisory messages between the network edge and the hosts, I think we are on solid ground. If a given set of hosts, on a given network want to invoke draconian admission control measures as a result of Flow State Exchange, that is up to them - but out of scope. In any case, the individual flows MUST still adhere to the basic congestion control algorithms that we are going to embark upon. There may be flows in the same QOS bucket that are not participating in the FSE algorithm. Even in that scenario, FSE data could be used by the participating hosts to decide which stream gets throttled. bvs -----Original Message----- From: rtp-congestion-bounces@alvestrand.no [mailto:rtp-congestion-bounces@alvestrand.no] On Behalf Of Michael Welzl Sent: Wednesday, July 25, 2012 9:13 AM To: rtp-congestion@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
On 7/26/12 12:14 PM, Bill Ver Steeg (versteb) wrote:
I like where this is going, as long as we understand that any FSE is advisory information that may or may not be used by a given set of hosts.
One underlying question is -- what actions will take place as a result of this information exchange? I do not think that this is a black and white question, and I think this is OK. As long as the behavior is "do no worse than if the FSE did not take place", we have not lost anything. In other words, if this information is made available to the hosts, and the hosts do not do anything with it - it is the exact same behavior as we have today. ACK to all that, except that, to keep things simple (and *only* for that reason), I actually considered the FSE to be located directly on the host where it's used. That is, no FSE server that multiple clients are talking to. No protocol for accessing it, only an agreement about what information to read/store, and usage recommendations.
However, for a set of hosts that does have some knowledge of the relative flow priorities, those hosts now have the information to "do the right thing". There are many proprietary examples of hosts that do this today, but they are all silo-ed and do not interoperate. The best example I can think of is in the IPTV world. There are N hosts behind a constrained last mile. They know about each other's streams. They know about the bandwidth allocated to the video flows, and the system knows how to mark packets. The hosts simply co-operate to stay below the constrained link BW. I'm not saying I wouldn't *like* such networked FSE usage... maybe one can just leave this possibility for the future and only agree on the minimum necessary things: usage within a single host, what to store, how to use it (as recommendations) for now. This wouldn't exclude extending the system to do what you describe above in the future.
However, we do need to be careful to stay away from mandating very heavy-weight methods. Old-style formal admission control methods are not desirable, IMHO. History has shown that such methods simply do get deployed into the areas in which we need to have flow visibility. As long as we think in terms of advisory messages between the network edge and the hosts, I think we are on solid ground. If a given set of hosts, on a given network want to invoke draconian admission control measures as a result of Flow State Exchange, that is up to them - but out of scope. I couldn't agree more. Advisory messages is exactly what I had in mind.
In any case, the individual flows MUST still adhere to the basic congestion control algorithms that we are going to embark upon. There may be flows in the same QOS bucket that are not participating in the FSE algorithm. Even in that scenario, FSE data could be used by the participating hosts to decide which stream gets throttled. Yes!
Michael
On 07/26/2012 03:36 AM, Michael Welzl wrote:
On 7/26/12 12:14 PM, Bill Ver Steeg (versteb) wrote:
I like where this is going, as long as we understand that any FSE is advisory information that may or may not be used by a given set of hosts.
One underlying question is -- what actions will take place as a result of this information exchange? I do not think that this is a black and white question, and I think this is OK. As long as the behavior is "do no worse than if the FSE did not take place", we have not lost anything. In other words, if this information is made available to the hosts, and the hosts do not do anything with it - it is the exact same behavior as we have today. ACK to all that, except that, to keep things simple (and *only* for that reason), I actually considered the FSE to be located directly on the host where it's used. That is, no FSE server that multiple clients are talking to. No protocol for accessing it, only an agreement about what information to read/store, and usage recommendations. For a first cut, I'd go even further and put it within a single process (the browser is an obvious candidate). This is very simple to realize without the cooperation of anyone else, as long as the information is available from the congestion control machines managing the individual flows.
What to store is interesting - even the key is a good question; should one store from/to/protocol/DSCP as observed on incoming packets, from/to/protocol/DSCP as inferred on the sending side, or something else? I'm very unclear on what algorithms one should run to detect that two flows are experiencing congestion at the same bottleneck (or not).
On Aug 3, 2012, at 4:05 PM, Harald Alvestrand wrote:
On 07/26/2012 03:36 AM, Michael Welzl wrote:
On 7/26/12 12:14 PM, Bill Ver Steeg (versteb) wrote:
I like where this is going, as long as we understand that any FSE is advisory information that may or may not be used by a given set of hosts.
One underlying question is -- what actions will take place as a result of this information exchange? I do not think that this is a black and white question, and I think this is OK. As long as the behavior is "do no worse than if the FSE did not take place", we have not lost anything. In other words, if this information is made available to the hosts, and the hosts do not do anything with it - it is the exact same behavior as we have today. ACK to all that, except that, to keep things simple (and *only* for that reason), I actually considered the FSE to be located directly on the host where it's used. That is, no FSE server that multiple clients are talking to. No protocol for accessing it, only an agreement about what information to read/store, and usage recommendations. For a first cut, I'd go even further and put it within a single process (the browser is an obvious candidate). This is very simple to realize without the cooperation of anyone else, as long as the information is available from the congestion control machines managing the individual flows.
I totally agree - I think we should just define the concept of an FSE, with what goes in and out (and how it's maintained), which is already hard enough. Where on the host the FSE is located should be up to the implementation. This means, you could have an FSE within the browser, as you suggest, plus (optionally) an FSE in the OS, which could then deal with coordination between processes. All of that should be optional and up to the implementor, and FSE implementations at both levels could fit the standard as long as we only define the interface.
What to store is interesting - even the key is a good question; should one store from/to/protocol/DSCP as observed on incoming packets, from/to/protocol/DSCP as inferred on the sending side, or something else?
True. I like to think of RFC2140 as a logical starting point, even though that's quite different in several ways (window-based, about TCP, ..). But yes, this is the tricky bit.
I'm very unclear on what algorithms one should run to detect that two flows are experiencing congestion at the same bottleneck (or not).
I think that's an easy one. From past experience, I think the IETF can and will not agree on a shared bottleneck detection mechanism. So I'm convinced that we should leave this open in the spec, and allow for any algorithm to do it -- but: flows that are considered to share a bottleneck should be returned by the FSE. At first, this probably means that FSEs will only be implemented in browsers, where bottleneck-sharing is known because it's the result of multiplexing data over the same five-tuple (UDP port pair). (assuming anything else would also mean that no congestion control for RTP over UDP could be done, I think - and so it's simply *assumed* that these flows share a bottleneck). Later, people could put FSEs elsewhere, e.g. in OS kernels or run them as a demon, and then, for that, they could use a shared bottleneck detection mechanism of their choice. There are several such mechanisms available, and it's perhaps worth surveying them and documenting that somewhere. Of course, 100% reliability doesn't exist... but my guess is that letting the FSE rely on a *mostly* reliable mechanism is better than assuming "no shared bottleneck" all the time. But anyway, I think we should leave this up to implementers. Cheers, Michael
Yuchung Cheng talk about "Client-aided Congestion Management for TCP" in ICCRG session seemed somewhat related to this. Not sure what can be reused, but the concept looks similar. /Stefan On Sun, Aug 5, 2012 at 4:53 PM, Michael Welzl <michawe@ifi.uio.no> wrote:
On Aug 3, 2012, at 4:05 PM, Harald Alvestrand wrote:
On 07/26/2012 03:36 AM, Michael Welzl wrote:
On 7/26/12 12:14 PM, Bill Ver Steeg (versteb) wrote:
I like where this is going, as long as we understand that any FSE is advisory information that may or may not be used by a given set of hosts.
One underlying question is -- what actions will take place as a result of this information exchange? I do not think that this is a black and white question, and I think this is OK. As long as the behavior is "do no worse than if the FSE did not take place", we have not lost anything. In other words, if this information is made available to the hosts, and the hosts do not do anything with it - it is the exact same behavior as we have today.
ACK to all that, except that, to keep things simple (and *only* for that reason), I actually considered the FSE to be located directly on the host where it's used. That is, no FSE server that multiple clients are talking to. No protocol for accessing it, only an agreement about what information to read/store, and usage recommendations.
For a first cut, I'd go even further and put it within a single process (the browser is an obvious candidate). This is very simple to realize without the cooperation of anyone else, as long as the information is available from the congestion control machines managing the individual flows.
I totally agree - I think we should just define the concept of an FSE, with what goes in and out (and how it's maintained), which is already hard enough. Where on the host the FSE is located should be up to the implementation. This means, you could have an FSE within the browser, as you suggest, plus (optionally) an FSE in the OS, which could then deal with coordination between processes. All of that should be optional and up to the implementor, and FSE implementations at both levels could fit the standard as long as we only define the interface.
What to store is interesting - even the key is a good question; should
one store from/to/protocol/DSCP as observed on incoming packets, from/to/protocol/DSCP as inferred on the sending side, or something else?
True. I like to think of RFC2140 as a logical starting point, even though that's quite different in several ways (window-based, about TCP, ..). But yes, this is the tricky bit.
I'm very unclear on what algorithms one should run to detect that two
flows are experiencing congestion at the same bottleneck (or not).
I think that's an easy one. From past experience, I think the IETF can and will not agree on a shared bottleneck detection mechanism. So I'm convinced that we should leave this open in the spec, and allow for any algorithm to do it -- but: flows that are considered to share a bottleneck should be returned by the FSE.
At first, this probably means that FSEs will only be implemented in browsers, where bottleneck-sharing is known because it's the result of multiplexing data over the same five-tuple (UDP port pair). (assuming anything else would also mean that no congestion control for RTP over UDP could be done, I think - and so it's simply *assumed* that these flows share a bottleneck).
Later, people could put FSEs elsewhere, e.g. in OS kernels or run them as a demon, and then, for that, they could use a shared bottleneck detection mechanism of their choice. There are several such mechanisms available, and it's perhaps worth surveying them and documenting that somewhere. Of course, 100% reliability doesn't exist... but my guess is that letting the FSE rely on a *mostly* reliable mechanism is better than assuming "no shared bottleneck" all the time. But anyway, I think we should leave this up to implementers.
Cheers, Michael
______________________________**_________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/**mailman/listinfo/rtp-**congestion<http://www.alvestrand.no/mailman/listinfo/rtp-congestion>
It looked interesting, but more complicated to me. By focusing on the sender side (which I think we can do, in our case) the problem space gets easier to handle. On 6. aug. 2012, at 13:55, Stefan Holmer wrote:
Yuchung Cheng talk about "Client-aided Congestion Management for TCP" in ICCRG session seemed somewhat related to this. Not sure what can be reused, but the concept looks similar.
/Stefan
On Sun, Aug 5, 2012 at 4:53 PM, Michael Welzl <michawe@ifi.uio.no> wrote:
On Aug 3, 2012, at 4:05 PM, Harald Alvestrand wrote:
On 07/26/2012 03:36 AM, Michael Welzl wrote: On 7/26/12 12:14 PM, Bill Ver Steeg (versteb) wrote: I like where this is going, as long as we understand that any FSE is advisory information that may or may not be used by a given set of hosts.
One underlying question is -- what actions will take place as a result of this information exchange? I do not think that this is a black and white question, and I think this is OK. As long as the behavior is "do no worse than if the FSE did not take place", we have not lost anything. In other words, if this information is made available to the hosts, and the hosts do not do anything with it - it is the exact same behavior as we have today. ACK to all that, except that, to keep things simple (and *only* for that reason), I actually considered the FSE to be located directly on the host where it's used. That is, no FSE server that multiple clients are talking to. No protocol for accessing it, only an agreement about what information to read/store, and usage recommendations. For a first cut, I'd go even further and put it within a single process (the browser is an obvious candidate). This is very simple to realize without the cooperation of anyone else, as long as the information is available from the congestion control machines managing the individual flows.
I totally agree - I think we should just define the concept of an FSE, with what goes in and out (and how it's maintained), which is already hard enough. Where on the host the FSE is located should be up to the implementation. This means, you could have an FSE within the browser, as you suggest, plus (optionally) an FSE in the OS, which could then deal with coordination between processes. All of that should be optional and up to the implementor, and FSE implementations at both levels could fit the standard as long as we only define the interface.
What to store is interesting - even the key is a good question; should one store from/to/protocol/DSCP as observed on incoming packets, from/to/protocol/DSCP as inferred on the sending side, or something else?
True. I like to think of RFC2140 as a logical starting point, even though that's quite different in several ways (window-based, about TCP, ..). But yes, this is the tricky bit.
I'm very unclear on what algorithms one should run to detect that two flows are experiencing congestion at the same bottleneck (or not).
I think that's an easy one. From past experience, I think the IETF can and will not agree on a shared bottleneck detection mechanism. So I'm convinced that we should leave this open in the spec, and allow for any algorithm to do it -- but: flows that are considered to share a bottleneck should be returned by the FSE.
At first, this probably means that FSEs will only be implemented in browsers, where bottleneck-sharing is known because it's the result of multiplexing data over the same five-tuple (UDP port pair). (assuming anything else would also mean that no congestion control for RTP over UDP could be done, I think - and so it's simply *assumed* that these flows share a bottleneck).
Later, people could put FSEs elsewhere, e.g. in OS kernels or run them as a demon, and then, for that, they could use a shared bottleneck detection mechanism of their choice. There are several such mechanisms available, and it's perhaps worth surveying them and documenting that somewhere. Of course, 100% reliability doesn't exist... but my guess is that letting the FSE rely on a *mostly* reliable mechanism is better than assuming "no shared bottleneck" all the time. But anyway, I think we should leave this up to implementers.
Cheers, Michael
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
On 7/25/2012 6:13 AM, Michael Welzl wrote:
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.
Correct, this was an issue I've been driving towards and promoting (without an actual proposal how to do more than share among the media streams).
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).
This is similar to (but more standardized than) some ideas about coordination among senders we've been thinking about in Mozilla
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.
Or a browser's HTTP engine interacting with the FSE (even if there are no media streams at that time). -- Randell Jesup randell-ietf@jesup.org
participants (8)
-
Bill Ver Steeg (versteb) -
Eggert, Lars -
Harald Alvestrand -
John Leslie -
Michael Welzl -
Randell Jesup -
Roy, Radhika R CIV (US) -
Stefan Holmer