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

[<[e-mail]>]

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

P> Well one could take a variety of actions on the reception of ECN (
   or loss) - the 3GPP specs suggest some interesting things... We've
   mentioned them as they're one of many possibilities.

> [BB]: I suggest there's no need to repeat things other people say
  unless they make sense. I still don't understand why these things
   make sense.
>

[PO'H]You don't see why FEC makes sense as congestion reaction (or
      you're not keen on FEC in general)?


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

Regards,

Ruediger