On Feb 20, 2007, at 4:51 AM, Pekka Savola wrote:
It seems that are assuming the transport needs to happen in the
packet itself. While this is a possible approach, I don't see that
it needs to be the only one. For example, a mechanism where the
mutually trusting network components would have another channel to
convey this information (e.g., using SNMP, IPFIX, or the like)
might also apply.
On this, I would note the history of Source Quench, which could also
be described in these terms. Source Quench was originally specified
in RFC 777 (and later 792) as an optional communication:
A gateway may discard internet datagrams if it does not have the
buffer space needed to queue the datagrams for output to the next
network on the route to the destination network. If a gateway
discards a datagram, it may send a source quench message to the
internet source host of the datagram. A destination host may
also
send a source quench message if datagrams arrive too fast to be
processed. The source quench message is a request to the host to
cut back the rate at which it is sending traffic to the internet
destination. The gateway may send a source quench message for
every message that it discards. On receipt of a source quench
message, the source host should cut back the rate at which it is
sending traffic to the specified destination until it no longer
receives source quench messages from the gateway. The source
host
can then gradually increase the rate at which it sends traffic to
the destination until it again receives source quench messages.
The gateway or host may send the source quench message when it
approaches its capacity limit rather than waiting until the
capacity is exceeded. This means that the data datagram which
triggered the source quench message may be delivered.
From a "building a service" perspective, an optional communication
is one I can't rely on receiving, which means that I also have to
have some other solution to the problem, which may in turn be
adequate in the absence of the optional service. RFC 1009 goes on to
make another interesting comment:
Two problems for a gateway sending Source Quench are: (1) the
consumption of bandwidth on the reverse path, and (2) the use
of gateway CPU time.
Generating new bandwidth use, and especially taking time away from
forwarding datagrams to do so, at a time when there is too much
traffic was deemed problematic.
We could discuss the history of the SQuID experiment, which did not
achieve wide deployment. The comments of KK Ramkrishnan (the inventor
of ECN at DEC in the 1980's) in RFC 1254 should be considered as well.
Another significant drawback of the Source Quench policy is that its
details are discretionary, or, alternatively, that the policy is
really a family of varied policies. Major Internet gateway
manufacturers have implemented a variety of source quench
frequencies. It is impossible for the end-system user on
receiving a
Source Quench to be certain of the circumstances in which it was
issued. This makes the needed end-system response problematic: is
the Source Quench an indication of heavy congestion, approaching
congestion, a burst causing massive overload, or a burst slightly
exceeding reasonable load?
To the extent that gateways drop the last arrived datagram on
overload, Source Quench messages may be distributed unfairly. This
is because the position at the end of the queue may be unfairly
often
occupied by the packets of low demand, intermittent users, since
these do not send regular bursts of packets that can preempt most of
the queue space.
I'll refer you in the end to the comments of RFC 1812, which I edited
by did not write:
4.3.3.3 Source Quench
A router SHOULD NOT originate ICMP Source Quench messages. As
specified in Section [4.3.2], a router which does originate
Source Quench messages MUST be able to limit the rate at which
they are generated.
DISCUSSION:
Research seems to suggest that Source Quench consumes
network bandwidth but is an ineffective (and unfair)
antidote to congestion. See, for example, [INTERNET:9] and
[INTERNET:10]. Section [5.3.6] discusses the current
thinking on how routers ought to deal with overload and
network congestion.
A router MAY ignore any ICMP Source Quench messages it
receives.
DISCUSSION:
A router itself may receive a Source Quench as the
result of
originating a packet sent to another router or host. Such
datagrams might be, e.g., an EGP update sent to another
router, or a telnet stream sent to a host. A mechanism has
been proposed ([INTERNET:11], [INTERNET:12]) to make the IP
layer respond directly to Source Quench by controlling the
rate at which packets are sent, however, this proposal is
currently experimental and not currently recommended.
Personally, I would want to ensure that any mechanism used, whether
in-band or out-of-band with the communications it applies to,
addresses the concerns raised around Source Quench.
However, to be clear, I have no objection to using the ECN field(s)
if that does not hinder the current use (or lack thereof) of ECN.
What I specifically don't want is to define new fields for PCN,
especially extension headers or IP options. I should have been
clearer with my objection.
OK, great
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf