Subject: [re-ECN] Viability issue #1

From: Leslie Daigle <[email-masked]>
Date: Thu, 05 Nov 2009 01:06:15 -0500

[This attempts to outline an issue that could be perceived as 
challenging the viability of congestion exposure work.  The goal is to 
capture the issue, as well as itemize reasonable supporting arguments 
(for viability) and remaining questions to be addressed.  Please respond 
with suggestions as needed for each section.  ]

Viability Issue #1

What are the points in favour of/against congestion exposure as an 
architecturally sound technique to specify for the Internet?  (NB -- 
this is about congestion exposure, as constrained in the agreed 
principles, not any particular proposal)?

Suggested:

1/ This is about network flows, not applications or services, so it will 
serve future network uses (application types).

2/ Congestion exposure provides mechanisms to declare awareness of 
whole-path congestion WITHOUT prescribing behaviours.

3/ This is also network agnostic in the sense that no pre-existing 
agreements or interpretations need be in place to make the congestion 
exposure work.  (*Accounting* for it is a separate matter, but that's okay).

Questions:

4/ To what extent is this dependent on an assumed network architecture 
where the major sources of content (and congestion) traverse transit 
networks, as opposed to being CDNs connected directly to access networks 
(for business purposes)?

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: <[email-masked]>
Date: Thu, 5 Nov 2009 12:41:51 -0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Leslie Daigle
> Sent: 05 November 2009 06:06
> To: [email-masked]
> Subject: [re-ECN] Viability issue #1
> 
> 

I would go further and say this is even about single packets in
isolation. Allowing each packet to inform the network of the cost (in
resources, not money) of conveying it to the destination

> whole-path congestion WITHOUT prescribing behaviours.

Yes, and more to the point almost any behaviour you wanted could be
built on top of congestion exposure...

> exposure work.  (*Accounting* for it is a separate matter, but that's

As long as this is specified in such a manner that middleboxes are able
to transparently forward the correct information then this is true

> networks, as opposed to being CDNs connected directly to access

Even if they are CDNs they are still going to potentially cause
congestion that someone may need to account for. Indeed many people
suggest most congestion is in the access... Congestion exposure is NOT
just about inter-network agreements. It also works intra-network
(imagine a company being able to relax their rules on network access
during working hours as long as their employees ensured they never
caused excessive congestion that might impact business-needs use of the
network).

> _______________________________________________
> re-ECN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/re-ecn

---

From: John Leslie <[email-masked]>
Date: Fri, 6 Nov 2009 09:52:25 -0500

>    serve future network uses (application types).

   The idea is right -- but it's hard to comprehend.

   Rather than "about", I'd say CONEX distinguishes "congestion" within
the forwarding networks from application or services congestion.

   We probably also need to introduce the point that at every forwarding
step, there's an indication of how much "congestion" is expected from
the flow of packets heading toward that path (one RTT ago).

   And rather than some vague "future network uses", we should perhaps
mention delay-sensitive traffic (which now isn't served at all well).

   (I wonder if we should start another thread on what "congestion"
means: granted, CONEX is pretty agnostic on the actual meaning, but it
feels to me as if folks need to escape the "congestion==packet-drop"
mindset in order to understand how CONEX can help without giving
"unfair" advantage to marked traffic.)

--
John Leslie <[email-masked]>

---

From: Leslie Daigle <[email-masked]>
Date: Mon, 09 Nov 2009 10:21:46 +0900

Hi,

> the forwarding networks from application or services congestion.

I think this highlights that there are 2 different points to get out.

The original point I was aiming for was -- taking application-specific 
approaches to handling congestion makes it harder to handle new 
applications -- unrecognized.

I understand your point to be slightly different - that this is handling 
network congestion, as opposed to managing application and service 
behaviour.

Leslie.

--

---

From: Matt Mathis <[email-masked]>
Date: Sun, 8 Nov 2009 20:23:04 -0500

> whole-path congestion WITHOUT prescribing behaviours.

One little detail: you only get "whole-path" congestion information
using full RE-ECN.  Loss based RE-feedback is not in general able to
reliably instrument upstream congestion.  To the extent that we want
to use loss based RE-feedback as a stepping stone to get to full
RE-ECN, we want to avoid charter and problem statement language that
it can't support.

Consider  "... downstream..."   or the less specific "... congestion
elsewhere on the path..."

As I indicated in a previous message, there are reasons to be
suspicious of applications that want to instrument congestion that
that the packets have already escaped.

Thanks,
--MM--