Subject: [conex] comments on draft-conex-mechanism-00.txt

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 12 Aug 2010 12:27:04 +0200 (CEST)

Hi.

Just subscribed to the list (missed the start of this WG), sorry, can't 
reply to another thread because I don't have the original email.

So, I've started reading draft-conex-mechanism-00.txt. I object to the 
writing:

"For an operator facing congestion caused
    by other operators' networks, building out its own capacity is
    unlikely to solve the congestion problem."

If traffic isn't DDoS or caused my malware, it's traffic the customer 
wanted. The traffic isn't caused by "other operators' networks", it's 
caused by customer interaction with customers on other ISPs networks, thus 
something the customer wants to do. The above writing perhaps has place in 
a text sent so the regulator by a an entity who wants to justify its 
actions and avoid regulation or repercussions, but I don't think it is 
appropriate in an IETF document.

Oh well, over to the more technical part:

7. Use cases. I don't agree on the three approcahes. Point 1 and 3 means a 
router has to handle flows, this doesn't scale. Point 2 involves the 
"router" being congested. Perhaps what's meant is that a link connected to 
the router is congested egress (because that's where the queue will be)?

As I've said before, we're going more and more to simple cheap devices 
with small buffers and forwarding tables that are really quick (TCAM or 
alike). These devices are not flow aware and they don't really do RED 
either (it's pointless considering their small buffers). It's an important 
consideration for this wg how this should be handled. I don't see any 
discussion about it...

7.1. Here it's said that flow-aware equipment is expensive, that's good. 
It's important to remember. Again, there is talk about "congested 
routers" which I think is the wrong term.

8. Here is a good point about congestion not being a secret. The problem 
is that the IP stack knows about it, but the user does not (apart from 
deducing this from what how the application is behaving ("slow")). As some 
has seen from my postings on other IETG lists, I think there should be 
user insight into performance (metrics how the IP stack is behaving so 
this can be exposed to the user). Could this be part of the work done in 
this WG, actually exposing the CONEX performance data to the user? I think 
this is an important point.

I don't really object to the work being done, it's just that since ECN 
hasn't caught on in real life (it's in most end user OSes nowadays, I 
don't know many network devices which are ECN aware) I don't really see 
how the new propsals are actually going to be deployed? Are the hardware 
guys involved in the discussions so we know how hard things are to 
implement?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 12 Aug 2010 12:08:06 +0100

Hi Mikael,

Thanks for the comments. However we have written two major revisions since
the version you read. It would probably be more useful if you read the
updated version (which has a different filename...).

<http://moncaster.com/conex/draft-moncaster-conex-concepts-uses-01.txt>
<http://moncaster.com/conex/draft-moncaster-conex-concepts-uses-01.html>

There is a -02 likely to ship by early September and there will hopefully be
a separate abstract mechanism draft released before the Fall IETF meeting.

The aim is to try and make ConEx as independent of ECN as possible - ECN
would provide a useful additional signal but the system could work with just
taildrop... Bob Briscoe (who is away this week) can explain to you how ConEx
actually provides a motivation to deploy ECN - the main reason that ECN has
not been deployed (or not turned on) is that the network currently gets
little or no benefit from it. ConEx can provide a benefit by giving the
network more information...

Regarding your comment about "simple cheap devices with small buffers" it
would be useful if you could give some good references to such devices. I am
assuming these are mainly aimed at core networks? We already know that most
congestion comes from the access and backhaul so it is those that are really
the key for ConEx...

{speaking as an individual...} ConEx certainly can be used to provide a user
with more information and that information is expected to influence a user's
behaviour. If you read section 6.2 of
<http://bobbriscoe.net/projects/refb/polfree_rearch08.pdf> it mentions how a
user might be able to make some use of the information. Realistically I
would expect the application writers to provide the interface, for instance
you might get an application that intelligently manages the user's
congestion control, allowing the user to prioritise their applications, or
which uses mouse focus to apply the priority, etc... It's not that this
information is purposely hidden from the user, rather up till now no one has
thought to make it available... 

Toby

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Mikael Abrahamsson
> Sent: 12 August 2010 11:27
> To: [email-masked]
> Subject: [conex] comments on draft-conex-mechanism-00.txt
> 
> 
> Hi.
> 
> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 12 Aug 2010 13:27:05 +0200 (CEST)

> <http://moncaster.com/conex/draft-moncaster-conex-concepts-uses-01.html>

Thanks, will read and comment separately.

> would provide a useful additional signal but the system could work with 
> just taildrop... Bob Briscoe (who is away this week) can explain to you 
> how ConEx actually provides a motivation to deploy ECN - the main reason 
> that ECN has not been deployed (or not turned on) is that the network 
> currently gets little or no benefit from it. ConEx can provide a benefit 
> by giving the network more information...

What I hav a hard time understanding is exactly what the network should do 
with this information.

> Regarding your comment about "simple cheap devices with small buffers" 
> it would be useful if you could give some good references to such 
> devices. I am assuming these are mainly aimed at core networks? We 
> already know that most congestion comes from the access and backhaul so 
> it is those that are really the key for ConEx...

Well, I know of a lot of networks that are built in a hierarchy like this, 
connected by dark/grey fiber:

Residential household
(10/100)
Basement switches connected in a ring
(gig)
Larger L3 switch
(10GE)
Core, which might consist of just mor larger L3 switches.
(multiple 10GEs)

In the above, taking Cisco as an example, these would be ME3400 for 
basement, 6500/7600 for Larger 10GE switch, and cores could be that as 
well. Most of the WS-67xx linecards have < 5ms of buffers and very little 
queue management. In this kind of network there are very little ways of 
congestion signalling.

> thought to make it available...

My thinking is that exposing this information to the user will make them 
aware of what's going on and can give metrics in quality measurement of 
different ISPs, which can improve the ability of the users to choose an 
ISP which actually is low or free of congestion in their network.

Congestion isn't a force of nature, it's when the ISP wants to oversell 
their network to be able to supply a lower cost service and/or increase 
profit margins. This might be fine, but it should be done openly and users 
should know about it and be able to act accordingly.

---

From: John Leslie <[email-masked]>
Date: Thu, 12 Aug 2010 07:38:45 -0400

Mikael Abrahamsson <[email-masked]> wrote:
> 
> So, I've started reading draft-conex-mechanism-00.txt.

   That I-D is of historic interest only, being a mistaken submission,
where both Toby and I missed the incorrect name. Were it for real, it
would be titled "draft-ietf-conex-mechanism".

> I object to the writing:
> If traffic isn't DDoS or caused by malware, it's traffic the customer 
> wanted. The traffic isn't caused by "other operators' networks",

   The intent was to talk about congestion _within_ other networks.
The wording was unfortunate, and IIRC is entirely gone from the "current"
I-D. BTW, even the "current" I-D is of largely historic interest, since
it is undergoing really substantial surgery to amputate discussion of
mechanism.

> 7. Use cases. I don't agree on the three approcahes. Point 1 and 3 means
> a router has to handle flows, this doesn't scale.

   There is a not-fully-resolved issue there. The authors have tried to
reword things so we can agree there is no need to handle flows; but in
any case there is no need for "routers" to handle flows: at worst, what
we call "policers" may have to keep some flow state for flows they will
police.

> Point 2 involves the "router" being congested. Perhaps what's meant is
> that a link connected to the router is congested egress (because that's
> where the queue will be)?

   Correct.

> consideration for this wg how this should be handled. I don't see any 

   Were this a WG document and I the document-editor, I'd say "send text."
However, that's probably premature.

   I will note that the intent is that congestion actually experienced
is the only thing to be marked by routers along the path: otherwise
there is no need for awareness, least of all modification of packets;
and routers which "never" experience congestion have no need to do
anything.

   It is not yet clear what to do about packet loss in routers that have
no congestion-marking ability; but the fall-through is simply to let the
transport protocol (at the receiver) recognize the loss.

> routers" which I think is the wrong term.

   Correct.

> this is an important point.

   IMHO that's out of scope for ConEx, though I think it appropriate to
briefly discuss what the users would like to see.

> how the new propsals are actually going to be deployed?

   ConEx _will_ be deployable in scenarios where only the end-hosts and
their ISPs are ConEx-aware. To the extent that no intermediate networks
actually drop packets, it will work flawlessly: to the extent packets
are dropped in intermediate networks, congestion will have to be inferred
by the receiver and information past the point where packets are dropped
will be incomplete. In a well-designed network, we believe this will be
rare enough to not be an issue.

> Are the hardware guys involved in the discussions so we know how hard
> things are to implement?

   I'll let "the hardware guys" speak for themselves: we do not intend
to ask them for anything beyond marking for congestion experienced, and
even that will be optional except for the congested links to and from
end-users.

   Deployment at those links will likely take years, true; but we're
chartered for experimental uses, and we believe we can get enough
deployment for experiments quickly enough.

--
John Leslie <[email-masked]>

---

From: John Leslie <[email-masked]>
Date: Thu, 12 Aug 2010 08:08:56 -0400

> Core, which might consist of just mor larger L3 switches.

   This is (IMHO) a reasonable thing to do, starting from scratch. I'd
love to see this be the rule for developing countries.

   But in the world I know, there's existing copper-pair, existing cable,
and existing cell towers -- all of which have a bottleneck between user
and ISP.

> queue management. In this kind of network there are very little ways of 

   I would disagree -- though if you mean current installed software,
you're likely right.

   It is premature to say just what the congestion signaling for ConEx
will be, but even ECN could be tuned to the "knee" so as to signal
buffers filling sufficiently before drop to be useful.

   We should perhaps also consider congestion-signaling de novo: what
would be statistically useful measures of pre-congestion (which do
not necessarily call for multiplicative-decrease of sending rate)?

> ISP which actually is low or free of congestion in their network.

   By all means... But for that purpose, users would want a very simple
review covering perhaps an entire month...

> their network

   I take exception to the claim that all ISPs "want to oversell".

   The fact is that ISP marketers discover that consumers _object_ to
too much information. The "overselling" you see comes from giving
customers the information "most customers" want in an environment 
where competition is limited.

   (Cable providers, of cours, face a particularly difficult tradeoff
here, since they _must_ have neighborhood aggregation points competing
for truly rare "channel" space. I sincerely hope that the rarity of
"channel" space may be overcome soon!)

> to be able to supply a lower cost service and/or increase profit
> margins.

   Low-cost is a critical customer consideration -- especially when
selling to folks who don't (yet) place a high value on Internet service.
Profit margins are driven by some weird economics, which IMHO would
disappear in an actually competitive market, but are endemic to
large monopoly structure.

> This might be fine, but it should be done openly and users should
> know about it and be able to act accordingly.

   You'll get no argument from me, there!

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 12 Aug 2010 15:49:08 +0200

Hi,

regarding the congestion marking/signaling capability of network devices, 
there are for sure several open questions. But in fact, although i would like 
to seen more discussion on the conex list about what is feasible here, is not 
really a conex topic.
If someone/an ISP want to use conex, he should be able to give any kind of 
congestion signal (loss/markings) to the endsystem. On the one hand  the 
mechanism used should signal enough congestion to achieve some kind of 
traffic management in the network and on the other hand it should not signal 
more congestion than needed because other entities will recognize that this 
specific network is congested and try to avoid to forward their traffic 
though (in the ideal case). That could mean a costumer will change its 
provider or an ISP will try to reroute its traffic.
But how the actual mechanism used looks like can differ a lot. This might be 
RED, this might be some kind of precongestion notification. This might be 
deployed just in nodes where it it likely to have congestion or just in 
border-routers or everywhere... And note, also if everybody would use RED, it 
is quite hard to find the right parametrization.
So regarding conex, if someone what to use conex information he has to make 
sure to signal the right amount on congestion at the right places... whatever 
that means every ISP has to decide for his own.

Mirja

On Thursday 12 August 2010 14:08:56 John Leslie wrote:
> > Well, I know of a lot of networks that are built in a hierarchy like
> > this, connected by dark/grey fiber:
> >
> > Residential household
> > (10/100)

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 12 Aug 2010 21:24:38 +0200 (CEST)

>   I would disagree -- though if you mean current installed software,

On the platforms I mentioned I'd say there isn't much possibility of 
getting this feature out of current hardware platforms.

> buffers filling sufficiently before drop to be useful.

With 5ms buffers, I don't see how buffer depth is of any use.

> not necessarily call for multiplicative-decrease of sending rate)?

Yes, using a policer and signalling congestion at 90% usage is absolutely 
a way to do this. It would be interesting to hear from hw manufacturers if 
they're interested in this though.

> review covering perhaps an entire month...

Perhaps, but information about what happened the last 5 minutes is also of 
interest.

>   I take exception to the claim that all ISPs "want to oversell".

Sure, I never made the claim that this was "all" ISPs.

> "channel" space may be overcome soon!)

It's always going to be a scarce resource. Shared media like that should 
be considered aggregation and not access, so cable companies need more 
intelligence in their CPEs (or they should stop building cascade networks, 
that's why we abandonded 10Base-[25].

> disappear in an actually competitive market, but are endemic to large 
> monopoly structure.

... which is exactly my point, congestion in the ISP network (not access) 
is a symptom of poor competition. This cannot be solved by technical means 
in a working group, it's more of a political/economical problem. That's 
why I have problems with the problem description seen in the drafts so 
var.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 12 Aug 2010 21:38:30 +0200 (CEST)

On Thu, 12 Aug 2010, Mirja Kuehlewind wrote:

> So regarding conex, if someone what to use conex information he has to 
> make sure to signal the right amount on congestion at the right 
> places... whatever that means every ISP has to decide for his own.

If we're going to use reserved bits or headers and stuff that routers 
should act on, I really want general consensus that this is actually 
deployable and solves a wide problem in a way the general ISP business 
actually would benefit from.

Considering one bit went to ECN and it's basically 9 years later 
completely unused in networks, I think there is a lesson to be learnt 
here.

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 12 Aug 2010 21:11:05 +0100

> Sent: 12 August 2010 20:39
> To: [email-masked]
> Subject: Re: [conex] comments on draft-conex-mechanism-00.txt
> 

Yes - the lesson is that we should ensure there is a proper (commercially
viable and attractive) path to adoption before we commit something to the
standards track! I think there is a much stronger argument for ConEx than
there was for ECN... (for one thing the network need not do anything if it
chooses not to and, unlike ECN, there may still be a gain from the system)

Toby