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

[Bob Briscoe <[e-mail]>]

Ken,

At 14:45 23/10/2012, ken carlberg wrote:
>Bob,
>
>thanks for the review.  I'll take a stab at some of the comments, 
>and leave some fo the others for Piers to respond to (or correct me 
>where he may have a different opinion :-)

> > S.5.2 Fault Tolerance
> > I don't see why either redundant (duplicate) transmission or FEC 
> are relevant to a document about using ECN, as opposed to loss, for 
> congestion signalling.
>
>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?

> > S.5.3
> > I wholly agree that flows that consider themselves important 
> could use a substantially less aggressive back-off. But I complete 
> exemption is of great concern to me. Therein lies a congestion 
> collapse. There is no need for complete exemption, if a flow can 
> respond very little to congestion. At least then if congestion gets 
> really bad, it will still respond a lot. But if congestion is not 
> so bad, it will seem pretty much unresponsive.
> >
> > I know you report experiments where ECN exemption has limited 
> effect on normal flows, but the experiments assume low numbers of 
> exempt flows relative to non-exempt. Each individual flow cannot 
> know whether that assumption holds, so making this assumption is a 
> recipe for boiling a network during an emergency - just when we need it most.
>
>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.


>We also would agree that it would be preferable to have a less 
>aggressive back-off algorithm for these otehrs users -- particularly 
>in the case of typically higher bandwidth video users.  There is an 
>ITU document that is also discussing this same topic.
>
>One thing to keep in mind is that the Reactions draft isn't meant to 
>be a recommendation of what should be done.  Its means to be 
>information and point out what can be done.  However, I think the 
>section can be improved a bit to make sure the concern you bring up 
>above is well understood.

Yup, certainly.


>and thanks again for the comments.

No problem. Now on to Piers's


Bob


>-ken

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design