[e2e] Can feedback be generated more fast in ECN?

[Eric A. Hall]

> >   It requires the trailing ACK to survive so that rwin on the
> >   sender can be shifted without affecting cwin.
> 
> why?  any of the ACKs can cause the sender to (partially)
> advance the window.

Your statement was that "the sender won't slow down" which implies that
it's next send will be an rwin full of data. If only part of the data from
the previous send is ACK'd then the next send will only be half of rwin
(ignoring the other aspects of timing and such). The only way this will
occur is if the trailing ACK is received. Previous ACKs will slide the
window some but not enough for it to be "same rate".

> >   It requires that the trailing ACK arrive within a reasonable
> >   amount of time.
> 
> I don't understand how this matters.  What delays would
> apply to certain acks and not others?  How would trailing
> ACK delay affect whether congestion signals are delivered?

Maybe I should have said "any ACK" rather than "trailing ACK". Anyway, if
the ACKs are late then recovery is likely to kick in (depends on multiple
factors but in a lossy environment such as this scenario it is easy to
imagine that it will happen sooner rather than later, especially since the
second or third ACK is likely to be a dupack from forward loss).

> > Even after all of that, it also assumes that the next burst won't
> > trigger another SQ or inbound loss, and that the subsequent SQ will
> > also be eaten while the trailing ACK won't, ad infinitum. We are
> > moving from marginal probability into fractional.
> 
> By then, ECN would have reduced the sending rate.
> SQ would not.  Eventually, enough SQ's may be generated to
> overwhelm whatever loss probability exists, so I concede
> that eventually (and too late) an SQ will arrive.  If this
> is all that is necessary to provide "reliable" congestion
> signal delivery in SQ, I think we've found our disagreement
> over semantics.

We are well into theoretical space with the discussion already. The
likelihood of both ends of a cross-country, asynchronous-routed link
collapsing simultaneously is nil. You can have the simulator win. :p

For the real-world problems like DDOS attacks, dynamic congestion and
one-way corrosion, SQ's early alerting wins. Which is more important to
the Internet community, current problems or theoretical scenarios?

Honestly, I want to know. How does ECN deal with DDOS attacks when the
packets never get into the destination network? Timeouts are okay when
zombies are cranking away? What timeouts? With SQ the code 0 alerts bounce
off the congestion point and effectively cancel the zombie senders (with
varying levels of success, granted). That works today, or it would work
today if SQ were operational. Or is SQ worse than suffering with DDOS,
still "too expensive for the routers", and "too much extra traffic" on
uncongested backpaths even though sexy ECN doesn't deal with it at all?

Yes, I am frustrated and angry.

Giving the list a break,

Eric

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/