[Tsvwg] terminology issues in draft-floyd-tsvwg-besteffort

[Bob Briscoe <[e-mail]>]

Mark, Sally,

Before I went off-list for a holiday over the last couple of weeks, I said 
I generally agreed with <draft-floyd-tsvwg-besteffort-00.txt>
but I had issues with some choices of terminology. Can I ask you to 
consider the following changes to help the debate be more precise.
But, before I start, I just want to emphasise that I agree that it is 
important for people to understand that:
- ECN is not as simple as drop
- policing bulk congestion is not as simple as no policing at all and
- measuring bulk congestion for border SLAs is not as simple as not having 
border SLAs.
Or more succinctly: enforcing fairness is not as simple as not enforcing 
fairness (which is pretty obvious).

1/ Simple?

The term 'Simple Best Effort' contains a value judgement about simplicity.

Many ISPs already limit their heavy users using various metrics: Volume 
caps, volume pricing, deep packet inspection (=infering an app implies 
heavy usage), or vaguely worded acceptable use policies tied to various 
forms of monitoring that allow them to issue email warnings, reduce 
priority and/or issue disconnection notices.

By saying that 'Simple BE' is the dominant traffic class in the current 
Internet, you are either discounting all this policing as "not really 
policing" or as "not really complex", or you are implying most ISPs don't 
do any of this or most ISPs aren't planning to do more of this.

What we're trying to do is provide the simplest possible principled and 
effective policing metric that is application-neutral and user-neutral; as 
an alternative to all the kludges being introduced that are complex and/or 
too blunt and/or non-neutral. It's most disheartening to be accused of 
making the world more complex, when we believe we're making it simpler than 
it would otherwise be.

The best way to avoid that value judgement altogether is to just say 
"non-policed" or "unlimited", which is what you actually mean. And it would 
be best not to claim (without evidence) that ISPs who don't do any limiting 
are still predominant.

2/ BE?

This resource allocation debate is not about policing solely BE scheduled 
traffic. It could just as easily be about policing AF (say). The core issue 
that concerns you is whether ECN has to be turned on or not, so the most 
precise term is surely "non-ECN".

Points 1/ & 2/ summarised: Something like "Unlimited Non-ECN" would be more 
precise and preferable to 'Simple BE'.

---
I also have three strong disagreements that might be just terminology, or 
might be misunderstandings of what we're proposing. All three are in areas 
where we have deliberately wanted to allow vendors and ISPs to come up with 
a range of solutions, which might explain your confusion. But it would be 
fairer on our proposal if it was judged on the set of these 3 choices that 
is both the simplest and still fully effective. The choices you have chosen 
to hilite are the ones we specifically do not recommend - the most complex 
and/or least acceptable.

It's tough on us to be accused of adding complexity when what we'd 
recommend is actually as pretty d@mn simple as enforcing fairness can get.

3/ User pricing: Flat monthly (in our simplest effective proposal).

Please don't imply we're advocating user congestion pricing, given the 
whole reason we brought re-ECN to the IETF back in 2005 was because we 
found a way to limit congestion without constraining how operators price 
their services to their customers. Specifically, re-ECN is designed to work 
with flat monthly pricing.

4/ User policing: Bulk per-customer (in our simplest effective proposal).

Please don't imply that we're advocating per-flow policing. Admittedly we 
have always shown how you could do either per-flow or per-user. Before 
Oct-06 when I wrote that I-D on dismantling flow rate fairness, the 
community wanted to be able to police flow rates, so we wanted to show we 
could. But we neither require it nor recommend it. Our per-user policing 
makes per-flow policing redundant (but it's still there if an IPS wants it).

For the avoidance of doubt, "Bulk per-customer" policing means policing all 
traffic crossing the customer's sending access interface using a bulk token 
bucket to regulate the bit rate of congestion marked packets to all 
destinations together.

5/ Economic infrastructure: Simple pair-wise relationships (in our simplest 
proposal)

Please don't imply we're making economic infrastructure more complex. All 
network layer relationships would still be between directly connected 
neighbours (pairwise).

Currently many border contracts between privately connected ISPs or between 
ISPs and a peering exchange include an element of usage charging (as well 
as interface capacity pricing). Whether based on volume, on some notion of 
peak demand, or on a hybrid. We propose adding a metric (congestion volume) 
that is only slightly less simple than monthly byte-volume.

However, congestion volume is much more effective, as it can be used to 
make networks precisely accountable for the costs they cause in other 
networks (unlike a volume metric, which depresses usage even when the 
capacity is there for it).

So most of the inter-domain contracts that currently include an element of 
usage might switch to using congestion volume. And those that don't include 
any form of usage measurements in their contracts might stick that way. 
That doesn't make any contracts any more complex.


Bob


____________________________________________________________________________
Bob Briscoe, <[e-mail]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    [phone]