Re: [re-ECN] Two questions about CONEX

[Fred Baker <[e-mail]>]

On May 7, 2010, at 11:24 PM, Stewart Bryant wrote:

> That causes me to wonder where CONEX fits in relative to IPFIX which is a mechanism that is designed to monitor the flows in a network and report this information to the network operator.

That is a fairly complicated question.

First, IPFIX is not at all lightweight. At the high end, to counter that, it is often statistical - collecting data on all flows is considered a lot of data and, if a reliable transport is used to deliver it, potentially a large amount of memory dedicated to the function. Setting or not setting a two bit field in the IP header is something that any device that can decrement a TTL or hop limit can easily do with effectively no additional overhead. If you're trying to consistently manage high end users, which is what conex is ultimately about, which can be implemented anywhere and gives you full information?

Second, IPFIX doesn't really measure the same thing as ECN does. What ECN does is note that at the point in time that a datagram is traversing a node, the node is or is not experiencing "congestion" as defined locally. The definition for that class of traffic at that point could be "integrated throughput rate exceeds <threshold>", "instantaneous queue depth exceeds <threshold>", or "mean queue depth exceeds <threshold>", and it might mean "marked with some probability" or "marked if the case is true". Whatever its definition, you can determine that the node in question saw something it called "congestion". IPFIX tells you what went through a system - between <time1> and <time2>, data flow <selector> passed some number of bytes and packets. You can now feed that into a simulator of some type, but at best it will give you an approximation of the behavior of the link conditioned by your assumptions, not "the behavior of the link".

Where I scratch my head with re-ecn is the impact of the re-introduction of the flag stream. It looks to me like a control system, which is presumed to be somewhere at a network edge, is supposed to be scoreboarding marks against IP addresses or IP prefixes, which sounds to me like the kind of overheads one sees in XCP, RCP, or the like, but with storage and discrimination in some form of IP address database. That worries me from a scaling perspective. I'm in favor of having ISPs be able to limit congestion in a reasonable way, but I'm interested in approaches that scale. I'm also concerned about what looks to me like a persistent under-run. If Alice sends Bob a stream of traffic, Bob replies noting her mark count, and she re-replies re-inserting that mark count, there is always some probability that her re-inserted reply is itself marked and Bob no longer cares. If the network is drawing broad conclusions from aggregated marks, it seems it would need to account for the under-run.

Another way in which I scratch my head is what one actually does. If we're OK with maintaining per-address or per-prefix state of some sort, I would find myself wondering about a variation on fair queuing that uses the later of "a time or sequence number dictated by the source address" and "a time or sequence number dictated by the destination address", and only keeps track of addresses/prefixes that have been recently used. That allows the ISP to be in control of its own congestion without the compliance of neighboring networks or the hosts in them. But that's just me.