Re: [PCN] Re: WG Review: Congestion and Pre-Congestion Notification(pcn)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]