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

[Bob Briscoe <[e-mail]>]

Piers,

One response, plus two redirects to Ken's thread, inline...


At 22:08 23/10/2012, Piers O'Hanlon wrote:
>Bob,
>
>On 23 Oct 2012, at 19:49, Bob Briscoe wrote:
>
> > Piers,
> >
> > At 16:19 23/10/2012, Piers O'Hanlon wrote:
> >> Hi Bob,
> >>
> >> Thanks for the review. Comments inline.
> >>
> >> On 19 Oct 2012, at 18:29, Bob Briscoe wrote:
> >>
> >> > Ken & Piers,

> >> But to be fair you have a point in the case of a direct 
> comparison of RFC3168 ECN or drop.  I think that the more important 
> aspect of using ECN is that it provide for back-off before loss 
> occurs - allowing for flows to adapt earlier and minimise loss.
> >
> > [BB]: There is a more subtle sense in which ECN reduces latency. 
> I just wrote it into the opening para of this draft I just posted:
> > <http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines-01>
> >
> > "  as ECN is
> >   used more widely by end-systems, it will gradually remove the need to
> >   configure a degree of delay into buffers before they start to notify
> >   congestion (the cause of bufferbloat).  The latter delay is because
> >   drop involves a trade-off between sending a timely signal and trying
> >   to avoid impairment, whereas ECN is solely a signal so there is no
> >   harm triggering it earlier.
> > "
> > This is an emergent property that would only happen if ECN became 
> predominant, so that the optimum point to set AQM parameters was 
> determined mostly by ECN users, not legacy (drop) users.
> >
>Ok sounds good - though isn't one still limited by the BDP queue 
>size needed to accommodate TCP flows?

No. If ever ECN users become the large majority, you still have a BDP 
/buffer/ that can accomodate TCP, but it becomes an optimal 
compromise to set a much tighter threshold on the AQM. The few legacy 
TCP users would see loss earlier, but the majority (ECN) users who 
see ECN earlier don't care, because it's not an impairment, it's only 
a signal. So their short flows etc still finish quickly without timeouts etc.



> >> > 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.
> >> >
> >> 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.
> >
>You don't see why FEC makes sense as congestion reaction (or you're 
>not keen on FEC in general)?

Ken has answered this one, and I've responded in the other part of this thread.

> >
> >> > 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.
> >> >
> >> True complete exemption probably should not be generally used.
> >
> > [BB]: I agree, if you delete 'generally' :)
> >
>I thought you might say that!

Again, this discussion is progressing in the Ken thread.

>Cheers,
>
>Piers
>
> >> Thanks,
> >>
> >> Piers.
> >
> > Cheers
> >
> >
> > Bob
> >
> >
> >
> > ________________________________________________________________
> > Bob Briscoe,                                BT Innovate & Design

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design