Congestion Exposure (ConEx) Concepts and Use Cases
draft-ietf-conex-concepts-uses-05

A fine document that would have been enhanced by a short exposure of the
Conex references to live up to the "entry point" claim.

---

Classic ASCII-art. Well done!

Initially, I put a DISCUSS-DISCUSS because I was missing some information to correctly review the draft (This was advised by Ron Bonica). Discussing with Wes Eddy off line, maybe I should have put "Defer". Anyway, sorry for the confusion. Now that I had a 1:1 with Eddy, many points are clarified, and here is my feedback.

- One of my confusion reading the draft was that I was missing the link with RFC3168. After a conf. call with Wes Eddy, I understand that your plan is to use an IPv6 destination option, and that RFC3168 is a very not required (but might be used, if I read http://tools.ietf.org/html/draft-ietf-conex-abstract-mech-03#section-3 correctly). It would be nice to say a few words about this in the draft. 

- From the charter: 

    The purpose of the CONEX working group is to develop a mechanism 
    by which senders inform the network about the congestion encountered
    by previous packets on the same flow.


Question about how to do define the notion of flow inside the IP layer?
I see an IPv6 destination option in http://tools.ietf.org/html/draft-ietf-conex-destopt-02, but I don't see any encoding for a flow in there?

- Section 1, Introduction
As described in Figure 1, congestion control currently relies on the transport receiver detecting these 'Congestion Signals' and informing the transport sender in 'Congestion Feedback Signals.'

Do you always assume that, because you receive a congestion signals for a specific TCP session, the congestion is for this entire session? I see more and more cases for which a router does a Deep Packet Inspection, and treat applications differently, as opposed to the 5 tuple. Is this a use case for CONEX? Without a DPI engine on the sender, I don't see how this could work...

- What is happening in case of ECMP? One router is congested, and not the other one. Is the CONEX enabled sender clever enough to mark only the affected flow (based on the 5 tuple)?

- Following on the two previous points, I would like to see the issues/limitations documented.
Issue 1: one round trip late
Issue 2: the congested device MUST support CONEX. The Sender MUST support CONEX
Issue 3: DPI engine must be supported on the sender, if we want to differentiate per application
Issue 4: ECMP (if this is one)
Issue 5: not UDP
etc..
From there, the use cases are limited. I see one though: managed services, bought by an enterprise customer, out of a single service provider

- Section 2.3

   "rest-of-path
   congestion" (also known as "downstream congestion") is the level of
   congestion that a traffic flow is expected to experience between the
   measurement point and its final destination. 

What is a flow? The draft doesn't tell if the congestion is at layer 3, layer 4 or layer 7.

   In contrast,
   the ConEx signals inserted into IP headers as shown in Figure 1
   indicate the congestion along a whole path from source to
   destination.

source and destination what? IP addresses, or IP address/protocol/ports, or maybe IP address/protocol/ports/session id.
That's a key question in my mind.

Same remark in section 2.4, what is user's traffic

      Congestion:  In general, congestion occurs when any user's traffic
      suffers loss, ECN marking, or increased delay as a result of one
      or more network resources becoming overloaded.

- Section 2.4 definitions
You define congestion here, while section 2.1 already defines congestion

   The definition used for the purposes of ConEx is expressed as the
   probability of packet loss (or the probability of packet marking if
   ECN is in use).  This definition focuses on how congestion is
   measured, rather than describing congestion as a condition or state.


- Section 3.1

   By
   deploying a congestion policer at the BRAS location, the network
   operator can measure the congestion-volume created by users within
   the access nodes and police misbehaving users before their traffic
   affects others on the access network. 


My issue (again) with this use case, is if the BRAS sees a high congestion-volume ratio, it will police all traffic from that users.
However, that users might at the same time be part of a webex call (voice + video), doing a backup, and downloading with P2P.
And the flow/session/application (to be clarified) you want to slowdown are the P2P, then then backup, and not the webex.

- 6. Security.
Am I able to send a message (from my own IP address) with an IPv6 destination option containing the IP address of my neighbor, so that his packets are slowed down, and I can benefit from the full cable infrastructure? Seems like an important question...

In general, this is a good high-level description of what the community should expect in the coming CONEX drafts.  I do have a few questions though...

1. The draft talks about attributing congestion-volume contributions.  Shouldn't there be some description of how that would be done?  That sounds like a lot of state to maintain when congestion begins to occur.

2. Conceptually, if a CONEX-aware device in a network sees 10 packets of varying size from a single source and all have these CONEX markings, how do I equate the congestion-volume contribution of that source?  Are there assumptions made about the packets' characteristics *in the last RTT* based on the packets seen in the current RTT?

I could use a little help understand the example in section 3.1.  Do I
have it right that ConEx is used to provide information about
congestion in a flow to devices that are not directly experiencing the
congestion?  In the use case in section 3.1, the congestion policer is
placed exactly at the point where the existence of congestion is
known.  Why is any signaling mechanism needed at all?

In the first paragraph of section 3.2, how does ConEx specifically
encourage the use of scavenger transport protocols, relative to other
congestion policing mechanisms?

Does the second paragraph of section 3.2 suggest that ConEx is used to
actively affect traffic management in a way that is not directly
related to congestion experienced at the user device?  That is, the
receiver uses artificially generated congestion signals to cause ConEx
marking that affects its received traffic.  This use case is fine,
except that labeling the receiver->sender signaling as "congestion
feedback" is no longer accurate.

This may be a DISCUSS-DISCUSS, but I would like to pose the following questions:

1) Can CONEX distinguish between congestion that occurs on the local network and congestion that occurs downstream?. For example, assume that my ISP deploys CONEX. Assume also that a loss-prone link connects my PC to the CPE router in my kitchen. The TCP stack on my PC will report lots of loss. My ISP will detect this and when it congests, it will penalize me even further, even though I am not contributing to loss on the ISP's network?

2)  Can CONEX distinguish between congestion that occurs on the local network and congestion that occurs upstream? For example, assume that my ISP deploys CONEX. Assume also that I subscribe to a stream that incurs loss before it hits my ISPs network.  My ISP will detect this and when it congests, it will penalize me even further, even though I am not contributing to loss on the ISP's network?

3) Is the applicability of CONEX restricted to access networks, where it is possible to deploy per-user policers at the distant end of the network from the user?

4) Can CONEX markings be used as an attack vector?

5) How will CONEX behave in networks where incoming traffic can be characterized as follows: 
     90% is streaming UDP over IP multicast 
    10% is TCP.

    In this example, assume that multicast traffic is responsible for 90% of the congestion and that the multicast receivers send traffic in the reverse direction very infrequently.

6) How will CONEX work in a transition scenario, when some transport layer stacks are CONEX aware and others are not.

7) Does CONEX encourage traffic originators to falsify congestion markings?

s2.2: Maybe:

   Congestion-volume is a
   property of traffic, whereas congestion describes *a property of*
   a link or a path.

s3.1: 1st para: manage really meanest throttle and management means throttling right ;)

s3.1: I'm obviously not hard over on either of these: Monitor is much a nicer term than policer, but maybe monitor is overloaded.  Also "police traffic" maybe "manage misbehaving".

s3.3: For give the security guy, but "scavenger transports" refers to ... Vultured TCP (vTCP)?

Section 2.4: what (if any) metric is used for
rest-of-path and upstream- congestion? Is it volume?
If so, or if not, be good to say that.