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

[ken carlberg <[e-mail]>]

Understood.  I'll need to give some thought as to how to exactly convey these points about QoS into the draft.

As for Conex, I was one of the early ones arguing for its formation, though in truth, I hadn't thought about entwining it in some form to the Reactions draft.  Again, some more stuff I'll need to think about.

cheers,

-ken


On Oct 24, 2012, at 3:11 AM, <[e-mail]> <[e-mail]> wrote:

> [RG] Not talking for Bob, just for me: ECN is used to inform senders,
> that they cause congestion and should reduce rate. What you seemingly
> propose to do by FEC or duplication is the opposite, increase the
> load. I think to have read that Skype behaves like that. I also
> recall that there was an early WLAN "QoS" implementation which
> simply ignored the resource sharing mechanism and thus looked
> for unfair advantage. If you are not aware of Bobs Conex efforts,
> please read into that. To me, Conex seems to be a reasonable
> approach to deal with senders reacting with FEC or duplication
> on ECN signals.
> 
> [RG] To be constructive: if an application requires QoS with a
> minimum bandwidth requirement scheme (would mean admission control
> in the network), then go for a propper QoS class. I'd recommend
> that for UDP flows without TFRC or any other possibility to
> reduce rate.
> 
> [RG] ECN should be used to trigger a reduction of load. Sure
> enough, also some RTP based applications benefit from ECN in that
> sense. So there's a point in your draft.