Subject: [conex] new internet draft on exposing conex throughput

From: "Georgios Karagiannis" <[email-masked]>
Date: Sun, 03 Apr 2011 12:59:53 +0000

Hi all

I have just submitted the Internet draft entitled: "Exposing Conex
Throughput", see
http://www.ietf.org/id/draft-karagiannis-conex-throughput-exposure-00.txt.

This document describes a possible implementation complexity problem
associated with the current Conex concept defined by the ConEx WG and it
proposes a solution to this. This problem occurs due to the fact that it
is complex to measure the congestion rate, at each intermediate Conex
enabled device. A conex enabled device can be for example, a policer or
an audit device. Moreover, this document provides a solution to this
problem, by measuring and monitoring the per flow throughput on each
intermediate Conex enabled device instead of measuring and monitoring
the per flow congestion rate on each intermediate Conex enabled device.

The mentioned problem is related to the fact that in the context of
Conex it is complex to measure the congestion rate, see [RFC5348] at
each intermediate Conex enabled device.  In particular, the main solution
proposed in [draft-ietf-conex-abstract-mech-01] on measuring
the congestion rate on an audit device is: "The auditor could monitor
TCP flows or aggregates of flows, only holding state on a flow if it
first sends a Credit or a Re-Echo-Loss marking.  The auditor could
detect retransmissions by monitoring sequence numbers.  It would
assure that (volume of retransmitted data) <= (volume of data marked
Re-Echo-Loss).  Traffic would only be auditable in this way if it
conformed to the standard TCP protocol and the IP payload was not
encrypted (e.g. with IPsec). ", from
[draft-ietf-conex-abstract-mech-01].

In other words, an audit device needs to keep per flow (individual or
aggregated) state after it receives a credit or Re-echo-Loss marking
in order to measure the per flow congestion rate. In addition to this
the audit device must be able to read the TCP header in order to
observe the TCP header numbers. This is complex to be implemented and
it is not always possible, e.g., when the IP payload is
encrypted (e.g. with IPsec). In this way the audit device is also
able to take into consideration also the number of ECN CE marked
packets that were dropped by nodes located upstream.

Note that in my opinion the same method
of measuring the congestion rate at a policer is required as the one
applied at the audit device.

This document provides a solution to this problem, by
measuring and monitoring the per flow throughput on each intermediate
Conex enabled device instead of measuring and monitoring the per flow
congestion rate on each intermediate Conex enabled device.

Comments are welcome!

Best regards,
Georgios

---

From: John Leslie <[email-masked]>
Date: Tue, 5 Apr 2011 07:36:10 -0400

> http://www.ietf.org/id/draft-karagiannis-conex-throughput-exposure-00.txt.

   Thanks for the work that went into this.

> the per flow congestion rate on each intermediate Conex enabled device.

   It's clear that you and I don't share the same view of what the
abstract-mechanism draft calls for.

   You are seeing flow-state being required at many ConEx nodes along
the path; I am seeing flow-state being optional at one ConEx node near
the receiver.

   Perhaps both of us are wrong... It would probably be good to clarify
the wording in abstract-mechanism to prevent such misunderstandings.

> [draft-ietf-conex-abstract-mech-01].

   I have no enthusiasm for keeping this much flow state. I understood
the flow-state noted in abstract-mechanism to be intended to monitor
packet loss near the receiver for a partial-deployment scenario where
it is likely that there will be a congested node which doesn't ECN-mark
(but instead drops the packet) _before_ the auditing device.

   (I am not convinced this is worth the effort.)

> packets that were dropped by nodes located upstream.

   This is true. It's _part_ of why I'm unenthusiastic.

> Note that in my opinion the same method of measuring the congestion
> rate at a policer is required as the one applied at the audit device.

   I wouldn't agree. My understanding of the policer function in
abstract-mechanism is that it's there to restrain the amount of
congestion-expected marking that enters the backbone.

> congestion rate on each intermediate Conex enabled device.

   Honestly, I don't think it would help; and it looks to be _really_
hard to reach sufficient deployment.

--
John Leslie <[email-masked]>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 5 Apr 2011 13:53:35 +0200

Hi John

Thanks for the comments!
Please see in line!

> -----Original Message-----
> From: John Leslie [mailto:[email-masked]]
> Sent: dinsdag 5 april 2011 13:36
> To: Georgios Karagiannis
> Cc: [email-masked]
> Subject: Re: [conex] new internet draft on exposing conex throughput
> 
> > associated with the current Conex concept defined by the
> ConEx WG and
> > it proposes a solution to this. This problem occurs due to the fact 
> > that it is complex to measure the congestion rate, at each 
> > intermediate Conex enabled device. A conex enabled device
> can be for
> > example, a policer or an audit device. Moreover, this document 
> > provides a solution to this problem, by measuring and
> monitoring the
> > per flow throughput on each intermediate Conex enabled
> device instead
> > of measuring and monitoring the per flow congestion rate on
> each intermediate Conex enabled device.
> 

Georgios: In my opinion without having flow state, and assuming that the ECN
CE marked packets 
might be be dropped on a communication path, then the current Conex concept 
might not work properly.

> 
>    Perhaps both of us are wrong... It would probably be good 
> to clarify the wording in abstract-mechanism to prevent such 
> misunderstandings.
> 
> > each intermediate Conex enabled device.  In particular, the main 
> > solution proposed in [draft-ietf-conex-abstract-mech-01] on 
> measuring 
>    I have no enthusiasm for keeping this much flow state. I 
> understood the flow-state noted in abstract-mechanism to be 
> intended to monitor packet loss near the receiver for a 
> partial-deployment scenario where it is likely that there 
> will be a congested node which doesn't ECN-mark (but instead 
> drops the packet) _before_ the auditing device.
> 

Georgios: In my opinion without having flow state, and assuming that the ECN
CE marked packets 
might be be dropped on a communication path, then the current Conex concept 
might not work properly.

> > it is not always possible, e.g., when the IP payload is encrypted 
> > (e.g. with IPsec). In this way the audit device is also 
> able to take 
> > into consideration also the number of ECN CE marked packets 
> that were 
> > dropped by nodes located upstream.
> 
>    I wouldn't agree. My understanding of the policer function 
> in abstract-mechanism is that it's there to restrain the 
> amount of congestion-expected marking that enters the backbone.

Georgios: Yes, but this policer, in addition to the policing policy that it
needs to have, it should be aware of the signaled exposed congestion and of
the 
measured congestion on the path! If the congestion on the path cannot be
measured accurately, then the policer will probably take wrong
decisions on e.g., it can police traffic that should not be policed. 
This will have signifficant implications when an accounting application is
used on top of the policer. 

Best regards,
Georgios

> 
> > This document provides a solution to this problem, by measuring and 
> > monitoring the per flow throughput on each intermediate 
> Conex enabled 
> > device instead of measuring and monitoring the per flow congestion 
> > rate on each intermediate Conex enabled device.
> > 
> > Comments are welcome!
> 
>    Honestly, I don't think it would help; and it looks to be 
> _really_ hard to reach sufficient deployment.
> 
> --