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

[ken carlberg <[e-mail]>]

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 :-)

> 1/ Where you refer to RFC6679 as more fine-grained information than TCP, you might want to refer to this one too, which the Vancouver TCPM meeting agreed to include in the TCPM charter:
> <http://tools.ietf.org/html/draft-kuehlewind-tcpm-accecn-reqs-00.txt>
> 
> There are currently two possible proposals to satisfy these requirements:
> <http://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-01.txt>
> <http://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-option-01.txt>

Agreed.  Under the context you mention in terms of more granular information, it sounds good to add text and the references to the above.

> 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.

> 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.

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.


> S.5.3
> "  This applies to all
>   flows that utilize some form of the rate control that is inversely
>   proportional to the loss rate, which includes TCP-like algorithms or
>   equation-based approaches.
> "
> s/inversely proportional to/inverse in some degree to/
> 
> "Inversely proportional to" means rate = k/p,
> where p is loss probability and k is a constant
> TCP New Reno    rate = k/p^0.5
> TFRC            rate = k/p^0.5
> TCP Cubic       rate = k/p^0.75
> Compound TCP    rate = k/p^0.8
> None have       rate = k/p

okey dokey

and thanks again for the comments.

-ken