[e2e] ECN vs. source quench

[B***@emc.com]

-> Sending the congestion signal directly back to the source
-> might seem like a
-> possible option for the IP layer to implement (source quench
-> was the name),
-> but in fact it is quite incompatible with many high-level
-> protocols.
I got exactly the opposite supportive argument when I read
RFC 2884 (http://www.ietf.org/rfc/rfc2884.txt). This RFC
clearly states that the explicit congestion signal is efficient
is most of the situations.

This is confused. The ECN congestion signal does not go directly
back to the source; it goes to the destination and is reflected back
to the source, piggybacking on TCP traffic. In contrast, source
quench goes directly to the source. This difference is important
for several reasons, including:
- ECN takes advantage of the destination being able to
reach the source (source quench may not, as ICMP
is not end-to-end).
- ECN takes advantage of the TCP destination being able to
retain state to retransmit the ECN signal (asking a
router to retain state for source quench retransmission
is problematic for a number of reasons).
- ECN introduces no new traffic (a conservative "do no harm"
property, as adding traffic to deal with too much traffic
has the potential to make things worse).

Coming back to compatibility and portability of network layer
congestion notification to higher level protocols, ECN for example,
is in fact implemented for TCP, UDP applications. Recent
transport protocols, like DCCP and SCTP also adapted the ECN
usage.

ECN for UDP - really?? How is it reflected back to the source
and what does the source do with it?

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
[phone] FAX: [phone]
***@emc.com Mobile: [phone]
----------------------------------------------------

[David P. Reed]

Post by B***@emc.com
ECN for UDP - really?? How is it reflected back to the source
and what does the source do with it?

Protocols implemented on top of UDP can make use of ECN information to do
their own (presumably "tcp compatible") congestion control, using whatever
control loops they implement on top of UDP.

For example, a "digital fountain" can rate-control its transmission source
to back off when congestion is encountered, even though "digital fountains"
never retransmit.

As I said, ECN is an IP layer function and has nothing to do with TCP in
particular - all it does is tell the endpoint about impending congestion
conditions the IP datagram encountered as it traversed the routers along
the route.