Subject: [conex] "traffic management" in draft-ietf-conex-concepts-uses

From: Alissa Cooper <[email-masked]>
Date: Mon, 18 Jul 2011 18:11:28 +0100

I've been reviewing draft-ietf-conex-concepts-uses-02 and may send a few emails about different things.

I'm wondering what is meant by "traffic management" as the term is used in the draft. Sometimes it seems to encompass only actions that operators might take; other times it seems to also include endpoint-controlled management of congestion (e.g., in section 3). Sometimes it seems to be used in a way that is synonymous with "congestion management"; other times it seems to take on the more expansive connotation (that I often find used in the UK), encompassing motivations beyond mitigating congestion (e.g., deferring capacity investment by reducing peak-hour usage).

If what we're really talking about is the management of congestion by network operators, it might be better to call it "congestion management" and only use the term when referring to network-based management. If some more expansive concept is intended, that probably needs to be clarified.

Alissa

---

From: John Leslie <[email-masked]>
Date: Mon, 18 Jul 2011 14:13:26 -0400

Alissa Cooper <[email-masked]> wrote:
> 
> I'm wondering what is meant by "traffic management" as the term is
> used in the draft. Sometimes it seems to encompass only actions that
> operators might take;

   That is what I took the term to mean.

> other times it seems to also include endpoint-controlled management of
> congestion (e.g., in section 3).

   Hmm... perhaps you mean:
" 
" 3.  Traffic Management
" 
"  Since 1988 congestion management has been the responsibility of the
"  end-systems in the Internet architecture.  The network signals
"  congestion to the receiver, the receiver feeds this back to the
"  sender and the sender is expected to reduce the traffic it sends.
" 
"  Nonetheless, since at least when Nagle proposed fair queuing in 1985
"  [RFC0970], it has been recognised that end-systems alone cannot be
"  entrusted with sharing out capacity between themselves.
" 
"  Since then capacity has been shared by a mix of traffic management
"  approaches, partly network-based (weighted round-robin scheduling,
"  weighted fair queuing, etc) and partly host-based (TCP).

   This looks like a wordsmithing oversight: I think Bob meant "mix
of congestion management and traffic management approches".

> Sometimes it seems to be used in a way that is synonymous with
> "congestion management";

   Could you give examples?

> other times it seems to take on the more expansive connotation
> (that I often find used in the UK), encompassing motivations beyond
> mitigating congestion (e.g., deferring capacity investment by
> reducing peak-hour usage).

   "Traffic Management", as I understand it, is something network
operators do, for a variety of reasons -- deferring capacity investment,
alas, is inevitably one of them. (It really doesn't help to ridicule it:
when the money simply isn't there, or the lead-time is too long, you have
to do _something_...)

> If what we're really talking about is the management of congestion by
> network operators, it might be better to call it "congestion management"
> and only use the term when referring to network-based management.

   I disagree. Network Operators _do_ "traffic management". One of its
effects is helping to manage congestion. But they lack tools which are
actually directed at congestion-management -- that is, after all, what
ConEx is _for_.

> If some more expansive concept is intended, that probably needs to
> be clarified.

   I wouldn't call it "more expansive" -- it's more like "the light is
so much better here!"

--
John Leslie <[email-masked]>

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 20 Jul 2011 18:07:24 +0100

Alissa,

Isn't traffic management surely a very general term that means 
"managing traffic" (self-evidently). It doesn't have to imply who is 
managing traffic. The word 'traffic' gives it an implication of 
managing the bulk of traffic, not individual flows. So it would 
generally be associated with an operator managing traffic. But it 
could also mean the overall outcome of an end-system doing congestion 
control on all its flows.

IOW, it's a useful general term for a range of functions that alter 
the overall profile of traffic.

We certainly have to use the term traffic management when talking 
about all the things operators do today (partly because they aren't 
directly managing congestion, and in some cases they aren't even 
trying to indirectly manage congestion).

We can say that ConEx allows operators to focus their traffic 
management on managing congestion. But I don't think we should then 
call it congestion management, because that would risk being confused 
with end-system congestion control.

Do you think a definition entry for this would help? Or if it said 
traffic management is managing traffic, would it just add empty bytes 
to the draft?

[BTW, in public policy circles, they use the phrase network 
management to mean operator's traffic management. I tell them this is 
liable to misinterpretation in the industry.]

Bob

At 18:11 18/07/2011, Alissa Cooper wrote:
>operators might take; other times it seems to also include 
>endpoint-controlled management of congestion (e.g., in section 3). 
>"congestion management"; other times it seems to take on the more 
>expansive connotation (that I often find used in the UK), 
>encompassing motivations beyond mitigating congestion (e.g., 
>deferring capacity investment by reducing peak-hour usage).
>
>If what we're really talking about is the management of congestion 
>by network operators, it might be better to call it "congestion 
>management" and only use the term when referring to network-based 
>management. If some more expansive concept is intended, that 
>probably needs to be clarified.
>
>Alissa
>_______________________________________________
>conex mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/conex

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 22 Jul 2011 19:23:26 +0100

Hi Bob,

I think if John's suggestion in this thread about the text in 3.1 is followed, that would help to clear up the endpoint-versus-network distinction. There are a number of places in the document where I do think it is implied that traffic management is a network operator function (e.g., second-to-last para on page 4, first use case in 5.4), so the 3.1 clarification would be consistent with those.

A definition entry, if it made clear that the term applies to managing traffic for numerous purposes other than managing congestion, could be helpful. That might serve to counter the implication of phrases like this one in 5.1, which could be understood to mean that the goal of traffic management is only performance-driven: "In order to ensure all customers get decent performance from the network, they subject the "heaviest" customers to some form of traffic management."

Alissa

On Jul 20, 2011, at 6:07 PM, Bob Briscoe wrote:

> Alissa,
> 
> Isn't traffic management surely a very general term that means "managing traffic" (self-evidently). It doesn't have to imply who is managing traffic. The word 'traffic' gives it an implication of managing the bulk of traffic, not individual flows. So it would generally be associated with an operator managing traffic. But it could also mean the overall outcome of an end-system doing congestion control on all its flows.
> 
> IOW, it's a useful general term for a range of functions that alter the overall profile of traffic.
> 
> We certainly have to use the term traffic management when talking about all the things operators do today (partly because they aren't directly managing congestion, and in some cases they aren't even trying to indirectly manage congestion).
> 
> We can say that ConEx allows operators to focus their traffic management on managing congestion. But I don't think we should then call it congestion management, because that would risk being confused with end-system congestion control.
> 
> Do you think a definition entry for this would help? Or if it said traffic management is managing traffic, would it just add empty bytes to the draft?
> 
> [BTW, in public policy circles, they use the phrase network management to mean operator's traffic management. I tell them this is liable to misinterpretation in the industry.]
> 
> 
> 
> Bob
>

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 26 Jul 2011 03:38:20 +0100

Alissa,

At 19:23 22/07/2011, Alissa Cooper wrote:
>Hi Bob,
>
>I think if John's suggestion in this thread about the text in 3.1 is 
>followed, that would help to clear up the endpoint-versus-network distinction.

I assume you mean this:

>>of congestion management and traffic management approches".

Well, if we define traffic management as the superset of ways that 
traffic is managed, including (rather than excluding) congestion 
management, then the original is OK, and it wouldn't make sense to 
say "a mix of congestion management and traffic management", just as 
it wouldn't make sense to say "a mix of oranges and fruit".

>There are a number of places in the document where I do think it is 
>implied that traffic management is a network operator function 
>(e.g., second-to-last para on page 4, first use case in 5.4), so the 
>3.1 clarification would be consistent with those.

Neither case implies traffic management is *only* something operators 
do. Again, if traffic management implies nothing about who is doing 
the traffic management, there will be places where we talk about 
operators doing it, but that doesn't imply we're saying no-one else 
can. Similarly, if I say 40% of women eat an orange per day, I'm not 
saying men don't eat oranges.

>A definition entry, if it made clear that the term applies to 
>managing traffic for numerous purposes other than managing 
>congestion, could be helpful. That might serve to counter the 
>implication of phrases like this one in 5.1, which could be 
>understood to mean that the goal of traffic management is only 
>performance-driven: "In order to ensure all customers get decent 
>performance from the network, they subject the "heaviest" customers 
>to some form of traffic management."

I'm happy to add a definition for traffic management, but as I said, 
its value won't be in the definition (managing traffic) but in riders 
about what it's not: it's not only performance-driven and it's often 
but not necessarily operator driven.

Bob

> "managing traffic" (self-evidently). It doesn't have to imply who 
> is managing traffic. The word 'traffic' gives it an implication of 
> could also mean the overall outcome of an end-system doing 
> congestion control on all its flows.
> >
> call it congestion management, because that would risk being 
> confused with end-system congestion control.
> >
> > Do you think a definition entry for this would help? Or if it 
> said traffic management is managing traffic, would it just add 
> empty bytes to the draft?
> >
> management to mean operator's traffic management. I tell them this 
> is liable to misinterpretation in the industry.]
> >
> >
> >
> > Bob
> >
> >> I've been reviewing draft-ietf-conex-concepts-uses-02 and may 
> send a few emails about different things.
> >>
> >> I'm wondering what is meant by "traffic management" as the term 
> is used in the draft. Sometimes it seems to encompass only actions 
> that operators might take; other times it seems to also include 
> >> If what we're really talking about is the management of 
> congestion by network operators, it might be better to call it 
> "congestion management" and only use the term when referring to 
> network-based management. If some more expansive concept is 
> intended, that probably needs to be clarified.
> >>
> >> Alissa

---

From: John Leslie <[email-masked]>
Date: Tue, 26 Jul 2011 08:42:25 -0400

> it wouldn't make sense to say "a mix of oranges and fruit".

   Clearly, if we include the phrase "traffic management" at all, we
are going to have to include a definition of it. Bob's definition
is just too far from what some others think traffic management is.

   FWIW, I consider "traffic management" to be something operators
do in order to share capacity between competing customers in a manner
which won't drive away customers; while I consider "congestion
management" to be something end-systems do to be good citizens and
avoid over-stressing the network.

   I do not agree with Bob that including all congestion management
as a subset of traffic management is a useful way to think of the
issues involved.

> saying men don't eat oranges.

   It _is_ reasonable to imagine that network operators in some
imagined world might take actions intended to "manage" "congestion",
as opposed to managing "traffic". IMHO, this isn't where we should
be aiming: we have traditionally assigned "congestion management"
to a higher layer than "traffic management".

   Nonetheless, in the same sense that network operators now do
Deep-Packet-Inspection, it is arguably reasonable for them to take
more aggressive actions against traffic known to contribute to
congestion -- and I would agree that such actions still deserve
to be called "traffic management".

   Where I think Bob and I disagree is in considering such actions
to _be_ "congestion management".

> but not necessarily operator driven.

   We're just going to have to keep pressure on Bob to refrain from
always starting definitions with "what it's not".

   Thus, I'll offer some definitions (not expecting them to be
acceptable, but trying to guide us into better weeds to wander in):
" 
" Traffic Management -- actions taken by Network Operators to
"   manage Layer-3 traffic in order to ensure all customers get
"   access to infrastructure of limited capacity.
" 
" Congestion Management -- actions taken automatically by programs
"   and operating systems at higher Layers in order to relieve
"   congestion known to exist somewhere in the path through the
"   networks used.

---

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 26 Jul 2011 13:42:15 +0000

> Clearly, if we include the phrase "traffic management" at all, we are going to have to include a definition of it. Bob's definition is just too far from what some others think traffic management is.

> FWIW, I consider "traffic management" to be something operators
do in order to share capacity between competing customers in a manner which won't drive away customers; while I consider "congestion management" to be something end-systems do to be good citizens and avoid over-stressing the network.

Just as a counter-example, note the title of RFC 6057: "Comcast's Protocol-Agnostic Congestion Management System", which is in alignment with Bob's definition.  :)

I agree that we need to have a common understanding of the terms we use in Conex.

-- Rich