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

[ken carlberg <[e-mail]>]

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.

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.  

cheers,

-ken