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