Subject: [re-ECN] Comments regarding Conex charter

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 25 Mar 2010 14:55:39 +0000

Hi all

I agree with the argumentation given in the different available Conex
drafts that such work is needed and that it is useful to start a Working
group in the area oc Congestion exposure.

However the current charter is not clear to me. The current charter
mentions the following WG description:

"The purpose of the CONEX working group is to develop a mechanism
to allow senders to inform the network of the level of congestion
they expect their packets to encounter end-to-end. This information
is currently only visible at the transport layer in the end systems.
With the CONEX mechanism, it will be possible to provide sufficient
information in each IP datagram so that any node along the network
path can see the expected rest-of-path congestion.

Once any node can see the impact it causes (and suffers) by sending
or forwarding packets, it will be possible to hold senders and whole
networks accountable for the congestion they cause downstream. The
CONEX mechanism could be used for mitigating distributed denial of
service (DDoS) attacks; simplifying differentiation of quality of
service (QoS); policing compliance to congestion control; and so
on."

>From this description is not clear to me whether the working group will
specify:

o) How the network will detect congestion?

o) How the network informs the source about this congestion?

o) How the network will use the information provided by the source
regarding the level of congestion?  In the above paragraph is mentioned
“it will possible hold senders and whole networks accountable for the
congestion they cause downstream.” . It is not clear to me whether you
want to say that the “network by using the information provided by the
senders could predict and mitigate or reduce possible congestion
situation that are occurring or could occur in the immediate future.”

Moreover, regarding the protocol solutions, in the given work items I
could find only find the following information:

"2. Specification
Specification of IPv4 and IPv6 packet structures to carry CONEX
information (header bits, interpretation)

3. Best Practices
Transport-related best practices and specifications for

	A. the timely transport of congestion information from the  destination
to the sender
	B. ensuring the trustworthiness of the CONEX information  (to mitigate
the threats identified in 1C)"

I do not see any work items on how the timely transport of congestion
information from the destination to the sender will be used.
According to the re-ECN solution, see URL below, the network adds
pre-congestion marking in the forward data path, the egress (or
destination) feeds its level back to the ingress (or sender), then the
ingress gateway (or sender) re-echoes it into the forward data path by
blanking the RE flag.  Then at any border of a domain, the
pre-congestion marking that every passing packet will be expected to
experience downstream can be measured to be the RE blanking fraction
minus the congestion marking fraction.

http://www.watersprings.org/pub/id/draft-briscoe-tsvwg-re-ecn-border-cheat-01txt

In my opinion two more work items could be identified, see below:

o)  provide a solution on how the sender re-echoes the feedback
information into the network, and how the network uses this re-echoed
information.

o) provide a solution on how the network could predict and mitigate or
reduce possible congestion situation that are occurring or could occur
in the immediate future by using the information provided by the senders

Best regards,
Georgios

---

From: John Leslie <[email-masked]>
Date: Thu, 25 Mar 2010 11:47:06 -0400

> group in the area oc Congestion exposure.

   :^)

> However the current charter is not clear to me.

   Then we should fix it!

> o) How the network will detect congestion?

   Likely not... (personally, I'm not sure we could reach an agreement
what we mean by "congestion"...)

> o) How the network informs the source about this congestion?

   I believe we're intending that we only treat how to inform the
_recipient_ and leave up to a transport protocol to inform the sender.

>    regarding the level of congestion?

   This is a major area of work for the proposed WG. I don't believe
we want to limit usage at chartering time.

   The intent is clear that any network router can know rest-of-path
expected congestion, and determine somehow whether congestion-so-far
exceeds the "expected congestion". Exactly what it might do in such
a case, IMHO, we do not intend to specify.

   My personal view is that there might be formal or informal
settlements -- leading to cost justification for infrastructure
upgrades. But I do not believe that is a charter issue.

> It is not clear to me whether you want to say that the
> ?network by using the information provided by the senders could
> predict and mitigate or reduce possible congestion situation that
> are occurring or could occur in the immediate future.?

   My view is that settlements are a good path to justify upgrades;
and that conversely, "deadbeat" network peers that refuse to pay
settlements deserve a lower priority for their traffic -- perhaps
_lower_ priority than traffic without any ConEx marking.

   YMMV, of course...

> Moreover, regarding the protocol solutions, in the given work items
> I could find only find the following information:
> <snip>
> 

   IMHO, any such specification would be premature: I expect various
mechanisms to be tried.

>     information into the network, and how the network uses this
>     re-echoed information.

   I think that specification of how to specify expected congestion
when an IP packet originates is the limit of our work. How a sender
might calculate that number seems out-of-scope.

> o) provide a solution on how the network could predict and mitigate
>    or reduce possible congestion situation that are occurring or
>    could occur in the immediate future by using the information 
>    provided by the senders

   I would be happy to participate in such work; but I'm not sure
whether it is a necessary part of ConEx work. IMHO, it would be a
bad thing to even _suggest_ that there should be only one way...

--
John Leslie <[email-masked]>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 25 Mar 2010 20:46:05 +0000

Hi John

Thanks for the reply!

Please see in line!

>what we mean by "congestion"...)

Georgios: Yes but I assume that this would be the first step before start
doing the work in Conex, or?

>_recipient_ and leave up to a transport protocol to inform the sender.

Georgios: but work item 3 of the Charter is about:
"Transport-related best practices and specifications for

to the sender"

Will the WG work on extensions of a transport protocol or will the WG
specify requirements for the transport protocol.

>upgrades. But I do not believe that is a charter issue.

Georgios: So the WG will not work on any mitigation or reduction of the
congestion!

>_lower_ priority than traffic without any ConEx marking.

Georgios: So in your opinion the Conex WG will not work on mitigating or
reducing congestion n the network.

>   IMHO, any such specification would be premature: I expect various

Georgios: But are you expecting that this work will be done within the
Conex WG? I do not see this as an Work item.
>might calculate that number seems out-of-scope.

Georgios: But if the sender receives feedback and re-echoes it, then the
sender would need to know what to re-echo or?

>bad thing to even _suggest_ that there should be only one way...

Georgios: So mitigating or reducing network congestion is out of scope.

Best regards,
Georgios

---

From: John Leslie <[email-masked]>
Date: Thu, 25 Mar 2010 17:21:27 -0400

> doing the work in Conex, or?

   My guess is that we would punt that question. If we agreed on a
definition, I think it would have to be by reference to some existing
document.

   My recommendation would be to leave that question open, and design
ConEx so it could work with many different definitions of congestion.

<snip>
> specify requirements for the transport protocol.

   I really couldn't say (though I think a charter ought to at least
hint one way or the other).

   For myself, I'd prefer to do as little as possible, and nothing at
all about standards-track extensions to any transport protocol.

> Georgios: So the WG will not work on any mitigation or reduction of the

   Individual WG members almost certainly would work on such schemes.
But I don't think a ConEx WG should seem to promise any mitigation --
rather we should limit ourselves to how a ConEx protocol might be used
in mitigation efforts.

> Conex WG? I do not see this as an Work item.

   I wouldn't know how to specify such a charter work item.

> Georgios: But if the sender receives feedback and re-echoes it, then
> the sender would need to know what to re-echo or?

   IMHO, ConEx should only specify the meaning of ConEx signals, not
how to calculate expected congestion. Any algorithm we might specify
would inevitably include a loop delay which could lead to oscillation.
(We might even have to specify damping functions to avoid oscillation.)

> Georgios: So mitigating or reducing network congestion is out of scope.

   IMHO, we're building a _tool_ which would be useful in mitigating
congestion, not defining a _process_ for doing so.

---

From: Matt Mathis <[email-masked]>
Date: Sun, 28 Mar 2010 18:56:59 -0400

So from this thread I realize that the ConEx charter probably needs
one more sentence.  Something like "ConEx will not change the
semantics of either loss or ECN based congestion indications, nor will
it change sender transport behaviors in response to congestion
signals."

Thanks,
--MM--
-------------------------------------------
Matt Mathis      http://staff.psc.edu/mathis
Work:412.268.3319   Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.

On Thu, Mar 25, 2010 at 5:21 PM, John Leslie <[email-masked]> wrote:
> _______________________________________________
> re-ECN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/re-ecn
>

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 29 Mar 2010 09:28:44 +0100

Matt,

>it change sender transport behaviors in response to congestion

Good idea.

t twice:
s/change/specify changes to/

ConEx will subtly change the semantics of congestion indications: it 
will switch on their significance and enforceability.

Also, in an evolutionary sense, I hope ConEx does intend to change 
sender transport behaviours, but not directly; only indirectly by 
creating incentives ;)

Bob

>--MM--

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design