Re: [tsvwg] Review of draft-carlberg-tsvwg-ecn-reactions-03

[Bob Briscoe <[e-mail]>]

Ken,

inline

At 20:08 23/10/2012, ken carlberg wrote:
>Bob,
>
> >> Its relevant in the sense that it is a *type* of reaction from 
> the ECN signaling.  One vendor has told me in private that they 
> have a preference for this approach, and I think its of value 
> because it introduces the reaction on an ass needed basis instead 
> of from the very begining and through the session.  But the gist of 
> your concern is taken and we should probably add text that if this 
> kind of reaction is taken, which would increase offered load, then 
> an additional reaction (eg, employing CC algorithm, swapping to a 
> lower load codec) should/must also be taken.
> >
> > I clearly don't understand what S5.2 is about (which may be taken 
> as a hint that the doc probably needs to explain better). I still 
> don't get it... redundancy & FEC fix loss. ECN isn't a loss, so why 
> would anyone trigger a redundant transmission or FEC after an ECN mark?
>
>because its generally a fine line between the ECN marking and the 
>point where one needs to acually drop the packet because of queue 
>overflow (keeping in mind that we don't want huge queues for RTP 
>flows).  We've done one simulation effort and a couple of 
>implementations.  And in the latter case, it was a bit of a 
>challenge to get that sweet spot of generating traffic (in our case, 
>from an actual video feed) that triggered the ECN markings without 
>overflowing the queue.  And even then, unless the feedback came back 
>soon enough and there wasn't a continually added influx of flows 
>from additional users (eg, a flash crowd), then the chances were 
>quite good that some packets would be dropped after the initial CE 
>feedback occured. If my application or session is considered mission 
>critical, then using FEC in anticipation of lost packets and only 
>done as needed versus the lifetime of the entire flowis a good thing.

The chances of much loss following ECN CE are, I assume, fairly low, 
so it seems very tenuous to be thinking of adding the complexity of 
FEC when a small amount of loss can probably be handled just fine.


>We'll definitely have to add some text to clarify our thought 
>process on this particular topic.
>
> >> > S.5.3
> >> points well taken.  Within the context of the IETF, ETS is a 
> generic term for preferential services that are deployed in some 
> form in some of today's cellular networks.  And the numbers in 
> terms of percentage of ETS users we used in our simulation are 
> reflective at a very high and abstract level of what exists today 
> in some cases.  (I'm sorry to be hand wavy, but I'm trying to be 
> careful in my statements).
> >>
> >> And we also agree that individual flows from the end-host/UE 
> perspective will not know what percentage of exempt users co-exist 
> in the same "area" where congestion has occured.  This is why we 
> added the word "authorized" to help distinguish the two sets in 
> that some added element needs to exist to help minimize the set of 
> exempt users.
> >
> > Even if you're talking about authorized users, if you get an 
> emergency, you might get an influx of authorized users into an area 
> to deal with the emergency. I don't need to teach granny that the 
> main characteristic of emergencies is unpredictability.
>
>the numbers I've come across with today's deployed services in some 
>cellular networks has shown that less than 1% within a cellular 
>footprint are these "authorized" users.  In our simulations, we 
>aimed at a worse case scenario of 10%.  And yes, unpredicability is 
>still a cause for heartburn.

I still think a nearly unresponsive algo would give you nearly 
exactly the same behaviour as exemption if 1% or 10% authorized users 
did happen, but it would still avoid boiling the network if you did 
get 90%. Whereas completely unresponsive would not.


Bob


>cheers,
>
>-ken

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design