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

[Michael Welzl]

> > When it all comes down to what a router has to do once it knows
> > about congestion, ECN merely has a router check a bit and possibly
> > set another one whereas SQ means generating a whole new ICMP packet.
> 
> This is the only really credible argument I have ever heard 
> against SQ and
> to tell you the truth I am not entirely sure I buy it. How 
> expensive is it
> for a modern piece of equipment to generate a Destination Unreachable
> message? Is it prohibitive?

It's just more work - and if this is a problem depends on the amount
of generated packets. Which, in turn, is a question of scalability.


> And you forgot about some of SQ's benefits:
(..)

all right   :)
I know there ARE benefits, I just didn't want to go through them
once again. Regardless of those benefits, the problems with SQ
need to be solved, or it's not feasible.


> > (2) Source Quench packets can be dropped, so they are not reliable. 
> > If data packets in the forward direction carrying the CE (Congestion
> > Experienced) bit are dropped, then the application detects packet
> > drops and uses packet drops as an indication of congestion, so this
> > is a robust indication of congestion.  And there are robust 
> mechanisms
> > that receivers can use to inform senders that a packet has been
> > received with the CE (Congestion Experienced) bit set.
> 
> TCP timeout occurs regardless of SQ. No difference.

This can only be true if you have a send-SQ-and-drop-the-packet
scenario in mind. Might make sense; as Zhang Miao mentioned before,
this way, the overall network traffic is not increased.
On the other hand, this packet would not be dropped with ECN.


> > (3) Even if well-done, Source Quench packets add traffic in the
> > reverse direction on what might be a congested path.
> 
> SQ adds a packet on the *uncongested* portion of the 
> end-to-end network
> (bounce occurs at the congestion boundary, not before). 
> Moreover, almost
> all networks today are full-duplex, so the message doesn't even travel
> over the same leg as the original application data which is being
> generated. This is contrary to ECN, which requires the messages to
> traverse the *known congested* leg of the end-to-end network.

Agree. In this regard, SQ is no worse than an ACK.


I think one of the problems with SQ is that all efforts to use it
were somewhat half hearted. I know of two related expired Internet
drafts, but Rogerio's thesis may be the first serious analysis.
I say "may be" because I don't understand portuguese   :)
But it still looks very interesting to me.

I think that SQ might be useful if it's given good analysis:

- should it be used in combination with ECN, so both sides are
  notified, or should the forward packet be dropped so traffic is
  not increased?

- can it scale? for instance, if senders don't rely exclusively
  on SQ and SQ's are generated as a fraction of total traffic, not
  at regular intervals?

- if "regular usage" of SQ does not scale, are there alternatives?
  like sending SQ only in times of *severe* congestion?

- if we make it scalable by limiting the amoung of SQ messages
  and it's still too much work for some routers, can't we offer
  it as an option? It may help reduce a router's load earlier.

- if we want it to scale, a router may need per-flow state ("I am
  not going to notify THIS flow again!"). This may only be feasible
  for traffic aggregates, not individual flows. So what about SQ
  signaling from core to edge routers in DiffServ?


My point is:

ECN makes sense for several reasons. I don't think it's correct to
see SQ as ECN's rival. And I don't think it will suffice to say
"SQ is better than ECN, let's do it". But it may make sense to use
it in a more sophisticated way, given thorough analysis.

Cheers,
Michael