[e2e] Explicit Transport Error Notification

[Christian Huitema]

> > Explicit error notification is just one way to distinguish
> > between losses due to transmission errors and losses due to
> > congestion. An alternative way is to use explicit congestion
> > notification, and assume that packet losses are due to other
> > factors -- e.g., only shrink the window on ECN, and expend it
> > on the ACK. There are obvious deployment issues, but these
> > could be solvved if NASA is operating in any kind of
> > controlled set-up. In any case, the ECN only option could be
> > simulated in NS...
> 
> I presume making sure that network nodes never have to drop
> packets due to queue overrun/resource shortage/etc. is among
> the "obvious deployment issues" ... ECN currently requires that
> drops be treated as congestion signals for this reason.

No, that specific problem ought to not be too bad, as long that a node
that is experiencing queue overrun/resource shortage/etc. still ECN
marks those packets that are actually going through. Remember that ECN
is a statistical process; it can work even if some of the signal is
lost.

Similarly, the argument that ECN marked packets could be later dropped
due to some transmission error is also weak. The system should work, as
long as the ratio of marked to unmarked packets is not affected by the
losses due to transmission errors.

The obvious deployment issue is that in order to rely solely on ECN, one
has to assume that all routers susceptible of experiencing queue
overrun/resource shortage/etc. will also be capable of performing ECN
marking if needed. As I said, we should only be ready to make this
assumption if the network is somehow special, or when ECN deployment has
reached a significant fraction of the router population.

In any case, looking at the NS simulation could be interesting.

-- Christian Huitema