Re: [re-ECN] Charter Question

["David Harrington" <[e-mail]>]

Hi,

Do we already have protocols that could help solve this problem
intra-domain, such as ipfix and psamp?

One of the concerns that has been raised is whether domains will be
willing to share this potentially-sensitive information across
domains.
As a vendor, if I supported a re-ecn, I would think I would be
motivated to allow the operator to decide not to share the info, and I
would implement a scrubbing mechanism (allow border routers to clear
the conex markers in traffic exiting a domain). The IETF cannot
dictate that deployments reveal this sensitive information, any more
than it could dictate that SNMP traps must be allowed cross-domain.

So maybe we should approach the problem in two steps:

1) determining how well existing standard protocols can be used to
effectively address the intra-domain congestion problem, and whether
specific enhancements, such as congestion-specific ipfix IEs, are
needed. This would give us forward progress on standard approaches for
monitoring congestion that might be deployed fairly quickly.

2) how to share information across domains. Since the major question
here seems to be whether domains would be motivated to share, maybe an
effort akin to INCH is needed for this piece. After we solve the first
problem, we can try to extend it to cross-domain, or use a different
mechanism for cross-domain reporting.

dbh

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Bob Briscoe
> Sent: Monday, May 17, 2010 6:56 AM
> To: [e-mail]
> Cc: [e-mail]; Woundy,Richard; [e-mail]
> Subject: Re: [re-ECN] Charter Question
> 
> Stewart,
> 
> At 06:38 08/05/2010, Stewart Bryant wrote:
> >On 08/05/2010 01:19, Woundy, Richard wrote:
> >>So now let's add Conex marking, in which the end hosts add
markings 
> >>to send feedback about end-to-end congestion into the network. Now

> >>the CMTS has a new data point -- information about whether there
is 
> >>upstream (ECN) or downstream (Conex) congestion 
> >>experienced/expected for a particular packet flow. The CMTS can 
> >>count 'total bytes' as well as 'congestion bytes' on a per modem 
> >>basis. As a result, the backend system can make a much better 
> >>determination about whether a subscriber's overall traffic is 
> >>dominated by LEDBAT or non-LEDBAT applications, without resorting 
> >>to DPI and other such schemes. And the CMTS only maintains another

> >>set of packet counters, without disrupting its primary job of 
> >>packet forwarding.
> >>
> >>-- Rich
> >This sounds like a relatively slow process - i.e. over a few
packets 
> >the host tell anyone who wishes to listen that it is seeing 
> >congestion on a flow. That sounds like it could be addressed by 
> >having the host send an OAM packet from time to time over the path 
> >rather than including the information in every packet.
> >
> >Stewart
> 
> An OAM based solution would be in scope as a solution to the ConEx 
> problem statement. However, we would need someone to write up a 
> protocol spec in detail, including inter-domain, then prove it is 
> resistant to cheating, etc etc. If this happens (unlikely) the w-g 
> can choose between candidate solutions.
> 
> Anyway, granular isn't necessarily bad. For instance, operators 
> generally use data volume on slow timescales, but a volume counter 
> still has to accumulate packet by packet. Congestion-volume is no 
> different - except you just count the volume of packets that are 
> congestion marked.
> 
> We should be open to any solution, whether granular or coarse, as 
> long as it solves the problem ConEx aims to address: that network 
> operators currently have no reliable way (fast or slow) to measure 
> which users contribute how much to congestion - at least not in
cases 
> where the congestion is occurring at a different point to where it
is 
> being measured and controlled - whether the two points are within 
> your own network, as in Rich's example, or in different networks.
> 
> 
> 
> Bob
> 
> PS. sorry for late reply.
> 
> PPS. The only feasible OAM-based system I am aware of is Katerina 
> Argyraki's (ref  below). I'm sure the IESG would not want this level

> of complexity in the Internet. Also it only solves one side of 
> congestion accountability: network to users, whereas re-ECN aims to 
> make networks accountable to users *and* users accountable to 
> networks.
> 
> Argyraki, K., Maniatis, P., Irzak, O., Ashish, S. & Shenker, S., 
> "Loss and Delay Accountability for the Internet," In: Proc. IEEE 
> International Conference on Network Protocols IEEE (October 
> 2007)  URL: 
> http://www-dsg.stanford.edu/papers/astra/astra-hotnets04-paper.pdf
> 
> 
> 
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design 
> 
> _______________________________________________
> re-ECN mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/re-ecn
>