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

[Tianbo Kuang]

David,


>>I agree. This is a general rule.
>
>There's a reason for this - it's more than a rule.  IP carries many
>protocols other than TCP (and one can even argue that there are several
>different "species" of TCP, if you couple in application behavior
>differences, such as FTP vs. Telnet vs. HTTP).
>
>The proper adaptive response to congestion MUST coordinate the requirements
>of both transmitter, receiver, and application layer.  The transport
>network cannot presume that "quenching the source" is the best
>response.  The assumption that shortening the latency before "quenching",
>and discarding packets is optimal presumes a particular congestion-control
>policy that makes sense only with long-hold-time, stable-rate flows.  More
>generally, applications have a lot of other things they can do to respond
>to congestion (rerouting, app level compression and prioritization, ...).


Agree.

>The real problem with SQ is that its name implies a semantics that is not
>general.  If the message were instead called "early source congestion
>notification" (the ICMP ESCN message), which was triggered only for IP
>packets that had a flag requesting such notification, and reflected through
>the IP layer to an application layer for handling, it would clearly be more
>general than ECN (it would handle multicast UDP traffic at least as well or
>better).  Eric Hall is right that the arguments against SQ are pretty weak
>or irrelevant.  There are some good arguments against focusing all one's
>congestion control effort on a router-based, path-based scheme, but they
>are arguments against ECN as well.

Not quite sure. Then the only difference between ICMP ESCN and ECN is that
ESCN can notify the congestion earlier than ECN does. However, ESCN does
exclude the receiver-based congestion control in the case of multicast,
where receiver heterogeneity is a big problem.

Looking into the fast notification argument, it acutally consists of two
parts: (1) Is it really faster? (2) Is congestion control the faster the
better?

To question (1), it depends on the congestion pattern of the Internet. My
conjecture is that most congestion occurs at the access point of network,
where bandwidth is scarce. This is especially true in the case of mulicast
(See M. Yanjnik, J. Kurose, and D. Towsley, "Packet loss correlation in the
MBone Multicast Network," IEEE Global Internet'96, London, UK, Nov. 96.). In
this case, the congestion point may be near the receiver most of the time,
which reduces the benefit of early notification.

To question (2), the question really is: is it better to do congestion
control in a RTT time scale, leaving the short transient absorbed by buffers
in the network, or is it better to do it some other way around? Does anybody
know any study about this time scale issue?

Cheers,

--Tianbo

------------------------------------------------------
  Kuang Tianbo
  TRlabs
  111-116 Research Drive
  Saskatoon, Saskatchewan S7N 3R3
  Tel: (306) 668-9325(office) (306) 343-9747 (home)
  kuang at sask.trlabs.ca
------------------------------------------------------