Subject: Re: WG Review: Congestion and Pre-Congestion Notification (pcn)

From: Pekka Savola <[email-masked]>
Date: Mon, 19 Feb 2007 15:19:48 +0200 (EET)

On Tue, 13 Feb 2007, IESG Secretary wrote:
> [logical components being:] encoding and transport along forward 
> path from marker to egress, metering of congestion information at 
> the egress, and transport of congestion information back to the 
> controlling ingress.

I'd like to see it explicitly stated that transporting congestion 
information in the (metered) IP packets themselves is out of scope. 
This should exclude designs such as adding IP options en-route, 
defining new extension headers, or modifying the packets in any, 
currently undefined way.  (I say this explicitly because based on a 
very quick look at the mailing list archives I saw discussion relating 
to IP header encoding and it unnerved me.)

> Reaction mechanisms at the boundary consist of flow admission and 
> flow termination.

In order to do flow admission, you'll first need to recognize a flow. 
How do you recognize at the borders (or in the core) which kind of 
flows should be considered to be treated as PCN?  The mechanisms for 
accomplishing this in an operationally feasible way don't seem to be 
discussed in the charter.

This may be easy if all the traffic you're interested of is using a 
few predetermined (and configured) protocols and port numbers, but I 
suspect that is not the case, and layer 7 packet inspection is not an 
option either..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Fred Baker <[email-masked]>
Date: Mon, 19 Feb 2007 08:27:30 -0800

On Feb 19, 2007, at 5:19 AM, Pekka Savola wrote:
> very quick look at the mailing list archives I saw discussion  
> relating to IP header encoding and it unnerved me.)

I dunno, I think that horse is out of the barn. In the TCP arena, the  
XCP and RCP proposals and RFC 3168 could each be described in those  
terms, and the pre-congestion notification proposals on the table all  
encode congestion information in the IP packets, mostly in the ECN  
field. I'll agree that they should not attempt to insert things into  
the packet (add an option), but using space already set aside in the  
packet needs to be on the table.

I would like to see some crossover between the TCP/SCTP congestion  
control proposals and the real-time pre-congestion proposals. That's  
not a matter of declaring something out of scope as much as it is to  
encourage thoughtful (and not knee-jerk) consideration of whether and  
how the two types of needs can be met.

The drafts I know to be relevant (you'll note that some are in pwe) are:

http://tools.ietf.org/html/draft-babiarz-pcn-sip-cap
   "SIP Controlled Admission and Preemption", Jozef Babiarz, 16-Oct-06,
   <draft-babiarz-pcn-sip-cap-00.txt>

http://tools.ietf.org/html/draft-briscoe-tsvwg-cl-architecture
   "An edge-to-edge Deployment Model for Pre-Congestion Notification:  
Admission
   Control over a DiffServ Region", Bob Briscoe, 25-Oct-06,
   <draft-briscoe-tsvwg-cl-architecture-04.txt>

http://tools.ietf.org/html/draft-briscoe-tsvwg-cl-phb
   "Pre-Congestion Notification marking", Bob Briscoe, 22-Oct-06,
   <draft-briscoe-tsvwg-cl-phb-03.txt>

http://tools.ietf.org/html/draft-briscoe-tsvwg-re-ecn-tcp
   "Re-ECN: Adding Accountability for Causing Congestion to TCP/IP", Bob
   Briscoe, 26-Oct-06, <draft-briscoe-tsvwg-re-ecn-tcp-03.txt>

http://tools.ietf.org/html/draft-chan-pcn-problem-statement
   "Pre-Congestion Notification Problem Statement", Kwok Ho Chan, 25- 
Oct-06,
   <draft-chan-pcn-problem-statement-01.txt>

http://tools.ietf.org/html/draft-davie-ecn-mpls
   "Explicit Congestion Marking in MPLS", Bruce Davie, 19-Oct-06,
   <draft-davie-ecn-mpls-01.txt>

http://tools.ietf.org/html/draft-ietf-pwe3-congestion-frmwk
   "Pseudowire Congestion Control Framework", Stewart Bryant, 2-Feb-07,
   <draft-ietf-pwe3-congestion-frmwk-00.txt>

http://tools.ietf.org/html/draft-rosen-pwe3-congestion
   "Pseudowire Congestion Control Framework", Eric Rosen, 19-Oct-06,
   <draft-rosen-pwe3-congestion-04.txt>

---

From: Pekka Savola <[email-masked]>
Date: Tue, 20 Feb 2007 11:51:14 +0200 (EET)

On Mon, 19 Feb 2007, [email-masked] wrote:
> Forward transport of the basic congestion information has to be in
> scope as Fred has pointed out.  Backwards transport needs to be scoped
> by application scenario - for example, backwards transport via SIP
> is clearly out of scope for the initial PCN work.  OTOH, not specifying
> how to actually move any of this information around would turn PCN
> into the moral equivalent an IRTF Research Group, which (IMHO) would
> be bad - at the end of the day, PCN needs to produce something that
> actually works (need "running code" in addition to "rough consensus").

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.

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.

---

From: Fred Baker <[email-masked]>
Date: Tue, 20 Feb 2007 07:00:03 -0500

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

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 20 Feb 2007 06:55:01 -0600

FWIW, Fred's retelling of the trail of tears for ICMP Source Quench (as the 
concept moved from "please do this" to "please don't do this") is also 
useful, but

> 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.

is, I think, his most important point.

This was the most critical comment when we were looking at advisory 
notifications in TRIGTRAN (also trying to "help" with congestion avoidance, 
but if you can't count on receiving the notifications, you're most likely to 
fail when there's congestion, and that's exactly the time you need to be 
most likely to succeed).

Thanks,

Spencer

---

From: Fred Baker <[email-masked]>
Date: Tue, 20 Feb 2007 09:31:22 -0500

On Feb 20, 2007, at 8:15 AM, Georgios Karagiannis wrote:

> I assume that you also have no objection on using the DSCP fields for
> this purpose.

actually, I do, at least in some ways that they might be used. The AF  
service (RFC 2597) is specifically designed to do as you say; EF  
isn't. setting the DSCP on an EF packet in a way that nullifies its  
EF behavior to communicate the onset of congestion mostly nullifies  
the EF service (which doesn't actually do much of anything when there  
is no congestion to perturb packet timing). So I would want any use  
of the DSCP to be coordinated with the other services that the  
datagram hopes for.

---

From: Lars Eggert <[email-masked]>
Date: Wed, 21 Feb 2007 10:12:01 +0200

> clearer with my objection.

Right, there are multiple ways to encode and transport congestion  
information to and from the egress. The charter has a milestone for  
the WG to discuss various options before picking one for the initial  
standards-track documents:

Nov 2007 Survey of Encoding and Transport Choices of (Pre-)Congestion
Information within a DiffServ Domain (Informational)

Lars

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Feb 2007 11:26:48 +0100

On 2007-02-20 15:31, Fred Baker wrote:
> service (RFC 2597) is specifically designed to do as you say; EF isn't. 
> setting the DSCP on an EF packet in a way that nullifies its EF behavior 
> to communicate the onset of congestion mostly nullifies the EF service 
> (which doesn't actually do much of anything when there is no congestion 
> to perturb packet timing). So I would want any use of the DSCP to be 
> coordinated with the other services that the datagram hopes for.

Exactly. The allowed uses of the DSCP are constrained by RFC 2474
and PCN can't go outside those constraints without causing unpredictable
breakage. That needs to be explicit in the charter, I believe.

While I'm writing, consider this assumption:

> (A) these components are deployed in a single DiffServ domain,
> where all boundary and interior nodes are PCN-enabled and
> mutually trust each other

That is fine from the point of view of the diffserv architecture,
which is strictly domain-based. However, it isn't a get out of
jail card for security: BCP 61 (RFC 3365) still applies. The
comment about mutual trust should probably be removed.

     Brian

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 20 Feb 2007 13:15:11 +0000

Hi Pekka

Best regards,
Georgios

On 2/20/2007, "Pekka Savola" <[email-masked]> wrote:

>PCN mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pcn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 20 Feb 2007 13:15:11 +0000

Hi Pekka

Best regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 21 Feb 2007 10:00:18 +0100

Hi Fred

I think that one of the goals of the PCN WG will be to investigate 
the implications of using ECN and/or DSCP for PCN encoding purposes.

Best Regards,
Georgios

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]] 
> Sent: dinsdag 20 februari 2007 15:31
> To: Georgios Karagiannis
> Cc: Pekka Savola; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [PCN] Re: WG Review: Congestion and 
> Pre-Congestion Notification(pcn)
> 
> 
> actually, I do, at least in some ways that they might be 
> used. The AF service (RFC 2597) is specifically designed to 
> do as you say; EF isn't. setting the DSCP on an EF packet in 
> a way that nullifies its EF behavior to communicate the onset 
> of congestion mostly nullifies the EF service (which doesn't 
> actually do much of anything when there is no congestion to 
> perturb packet timing). So I would want any use of the DSCP 
> to be coordinated with the other services that the datagram hopes for.
>

---

From: [email-masked]
Date: Mon, 19 Feb 2007 11:49:37 -0500

Pekka,

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------