Subject: Re: [conex] Discussion of new Use Cases pt 1

From: Alissa Cooper <[email-masked]>
Date: Tue, 1 Mar 2011 10:15:21 +0000

Dave,

I don't have strong feelings about Approach 1 vs. Approach 2. I just  
think when we discuss existing or new use cases, we need to be clear  
about what metric (or whatever word people want to use instead of  
"metric") they are based on and whether those metrics all measure the  
same thing, whether they can be derived from each other, or whether  
they measure different things. Otherwise it becomes unclear what a use  
case is "using."

I sensed some confusion about this at IETF 79 and was sensing it again  
on the list. But if it's just my confusion, we can ignore it and move  
on.

Alissa

On Mar 1, 2011, at 1:30 AM, Mcdysan, David E wrote:

> Hi Alissa,
>
> Some responses in line below.
>
> Thanks,
>
> Dave
>
> On 2/26/11 7:21 AM, "Alissa Cooper" <[email-masked]> wrote:
>
>> Hi Dave,
>>
>> Couple of questions inline...
>>
>> On Feb 25, 2011, at 2:17 PM, Mcdysan, David E wrote:
>>> The proposed measure from the text that Toby sent from my draft for
>>> this
>>> use case is that of burstiness (I.e., peak/average) where the
>>> incentive
>>> peak is the"flat rate" or "bandwidth tier" purchased.
>>> ...
>>>
>>> Let me illustrate by an example. If conex could send longer-term  
>>> user
>>> burstiness to the congested shared resource, then a mechanism (to be
>>> described in the mechanism draft) at that point could
>>> drop more traffic from class B non-bursty users so that bandwidth
>>> tends
>>> to equalize between the two user classes
>>> Implement a bandwidth tier AND burst duration pricing scheme, with
>>> appropriate mechanisms to provide a burst duration longer than the
>>> shapers
>>> widely used today
>>>
>>
>> It seems to me that there are two different approaches being taken to
>> what is or is not in scope for both the use cases and the mechanism
>> definition:
>>
>> Approach #1:
>> a. Assume that the CONEX mechanism will be used exclusively to signal
>> the amount of congestion encountered by previous packets on the same
>> flow
>> b. Document the different uses to which that signal could be put
>> (traffic management, incentivizing scavenger services, etc.) in the
>> use cases draft
>> c. Document how the signal is set in the mechanism draft
>>
>> Approach #2:
>> a. Assume that the metric that CONEX will signal is open for
>> discussion, or that the mechanism may signal multiple different  
>> metrics
>> b. Document use cases for a variety of different potential metrics in
>> the use cases draft (congestion encountered previously on same flow,
>> long-term user burstiness as you describe above, possibly others)
>> c. Document how network nodes could respond to CONEX signals to
>> effectuate particular outcomes (dropping more traffic from non-bursty
>> users as you describe above)
>>
>> It seems as though you are taking approach #2 whereas others may be
>> taking approach #1, and these two approaches probably need to be
>> reconciled. I don't see how the same mechanism can signal both
>> congestion previously experienced on the path and peak/average  
>> sending
>> rate (although I'm happy for you or someone else to explain how it  
>> can
>> be done). If it can't be done, then it seems like we are talking  
>> about
>> signaling two different metrics.
>>
>> If we are focused on a single metric, then I think we need to  
>> document
>> use cases for that metric. If there are multiple metrics, we should  
>> be
>> clear about which use cases make use of which metric. And in either
>> case, I thought the point of the mechanism draft was to explain how
>> the chosen metric is measured so that it can be encoded at the IP  
>> layer.
>>
>> Alissa
>
> Quoting from the IETF 70 meeting minutes
>
> "ConEx Concepts and Abstract Mechanism
> draft-mathis-conex-abstract-mech-00 "
>
>
> Snipped
> " MB - not asking about sending to IESG, just asking about adoption  
> - do
>          people have comments?
>
>          Dave McDysan (DM) - charter related question - first result  
> is
> usage
>          scenarios document - other docs will not see publication  
> until
> that is
>          done - have already had questions on list about additional  
> use
> cases.
>          if we adopt this as the mechanism document then we foreclose
> use-case
>          discussion. there are use cases being elaborated that aren't
> supported
>          by the mechanism, so we could be going round in circles here.
>
>          MB - are you envisioning additional use cases that could  
> not be
> satisfied
>          by this mechanism?
>
>          DM - yes
>
>          MB - is this a little different or a lot?
>
>          DM - could be a lot different. this is a good approach for  
> short
>          timescales, but could do something longer term, slow path.
>
>          MB - so you would like to agree use cases?
>
>          Leslie Daigle (LD) - i would like to support adopting  
> mechanism
> document.
>          just don't use it as a blunt instrument to bludgeon people
> proposing new
>          use cases.
>
>          MB - would that work for DM?
>
>          DM - yes, if that decision can be documented.
>
>          MB - yes, it will be documented, I will remember."
>
>
>
> I interpreted the above as something like Approach 2 was acceptable  
> -- a
> use case did not need to align with the currently documented abstract
> mechanism. If others have a different interpretation, please respond  
> to
> the list.
>
> Also, the way the prior version of the use case draft was written was
> closely tied to the (re-ECN) mechanism (Approach 1) and the  
> agreement from
> the IETF 78 meeting minutes was to separate these. I provided a  
> detailed
> set of comments toward this end.
>
>>
>>>
>>> Thanks,
>>>
>>> Dave
>>>
>>>
>>> On 2/24/11 5:11 PM, "John Leslie" <[email-masked]> wrote:
>>>
>>>> STUART VENTERS <[email-masked]> wrote:
>>>>>
>>>>> Let me make sure I understand this use case and it's desired
>>>>> outcome:
>>>>>
>>>>> Consider 2 users A, and B.
>>>>>  A sends at a low rate all the time.
>>>>>  B sends only a congestion causing bunch during busy times.
>>>>>  A sends many more bytes per month than B
>>>>>
>>>>> Which is the 'heavy' user (I think B)?
>>>>
>>>> I don't think we should assume that...
>>>>
>>>>> Are we looking for a way for service providers to determine
>>>>> 'equitable'
>>>>> costs for these behaviors, or a way to make the system forwarding
>>>>> behavior for these two load is somehow 'equitable'?
>>>>
>>>> To some degree, Dave has to speak for himself, but IMHO this issue
>>>> is
>>>> about being able (under ConEx) to better inform a provider's
>>>> decision.
>>>> I'm nearly positive Dave doesn't mean for us to argue what balance
>>>> between
>>>> these two is "equitable".
>>>>
>>>> At first blush, it would seem "B" should "expect" congestion  
>>>> losses,
>>>> while "A" might not. Current non-ConEx methods tend to punish "A"
>>>> more
>>>> than "B"; and I do suspect Dave is suggesting a different balance
>>>> might
>>>> be appropriate.
>>>>
>>>> Nonetheless, IMHO "A" should expect congestion losses to increase
>>>> during periods of heavy use -- unless s/he buys better-than the
>>>> vanilla
>>>> best-effort service.
>>>>
>>>> --
>>>> John Leslie <[email-masked]>
>>>> _______________________________________________
>>>> conex mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/conex
>>>
>>> _______________________________________________
>>> conex mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/conex
>>>
>>
>
>

---

From: STUART VENTERS <[email-masked]>
Date: Tue, 1 Mar 2011 10:56:47 -0600

All,

After thinking about Allissa and Dave's discussion, here's my 2c for a CONEX congestion definition:

Definition for the kind of congestion that CONEX is trying to expose in a statistically multiplexed routing cloud:

Congestion is when a packet's forwarding behavior is adversely affected because of the traffic load caused by other packets in the cloud.
   'Adversely affected' means dropped or delayed more than the minimum delay seen in an otherwise idle cloud.
   'Other packets' means either packets from other users or packets from the same user.

When a packet gets affected simply because a shaper or policer says that a specific flow or user is sending more bits that the traffic contract allows, 
   that doesn't feel like congestion, but rather traffic management.

On the other hand, if the shaper were affecting packets because it sees the cloud is near or at congestion, then that effect feels like congestion.
    (Because traffic management is telling the user that there is, or soon will be congestion.)

The definition is focused on the discussion, so I may have completely missed some other aspect of congestion?

Under this definition, it might turn out that CONEX needs to expose both traffic management and congestion behaviors.
  I don't yet see the need for this, but could easily be persuaded by a use case.
  It would just be unfortunate if we had to muddy the definitions for the two in order to include the TM behaviors.

Cheers,

Stuart

---

From: John Leslie <[email-masked]>
Date: Tue, 1 Mar 2011 12:37:38 -0500

STUART VENTERS <[email-masked]> wrote:
> 
> Definition for the kind of congestion that CONEX is trying to expose
> in a statistically multiplexed routing cloud:
> 
> Congestion is when a packet's forwarding behavior is adversely affected
> because of the traffic load caused by other packets in the cloud.
> - 'Adversely affected' means dropped or delayed more than the minimum
>   delay seen in an otherwise idle cloud.
> - 'Other packets' means either packets from other users or packets from
>   the same user.

   This is a good start at discussing what we think we're talking about.

   So, let me take it as a start, rather than criticize its completeness.

   (I should perhaps criticize "Congestion is when", but let me reserve
that issue for later.)

   There is indeed good work going on to derive a measure of "congestion"
from transit-time, assuming that transit-time includes only minimum
latency plus queueing delays. (There are obvious problems with that
assumption, which I won't discuss.)

   Assuming we could actually collect useful queueing-delay numbers, it
is quite reasonable to assume them to represent a type of "congestion".

   BTW, I have discussed defining "congestion" on the ICCRG list,
starting Sat, 4 Feb 2006 16:03:28 -0500:
] 
] To me, congestion is the condition where a packet can't be sent
] "immediately" (meaning perhaps that it can't be queued as the next
] packet to be sent).

   (I derive that from a dictionary definition of "congestion: to
cause an excessive accumulation...")

   We could reasonably come up with a better definition of "immediately",
but I contend that it would be different for every class of traffic, so
I start from the most restrictive.

   But I digress...

   I don't believe time spent on arguing how much queueing corresponds
to "zero" congestion is helpful.

   Regardless, we do hit a discontinuity when the queue "fills" and a
packet is dropped; and many folks use "congestion" to refer to that
discontinuity.

   ECN came along to moderate that discontinuity: instead of dropping
the packet, we'd enforce Random-Early-Detection and at the tipping-point
of RED we'd ECN-mark the packet instead of dropping it. Assuming well-
behaved sender-receiver pairings this would reduce the need to drop
packets more-quickly than TCP-like protocols could do by detecting a
drop.

   ECN deployment is spotty-at-best -- possibly because nobody sees a
reason to trust the sender-receiver pairings...

   Getting back to Stuart's definition:

   I think "caused by" is the wrong wording. Necessarily, it is the
fact that packet-arrival-rate exceeds packet-forwarding-rate that
"causes" queuing delays. It makes no sense to try to assign "blame"
for this to individual senders -- except in the limiting case where
a sender's packet-sending-rate exceeds the available-forwarding-rate
of a particular forwarder; and for that limiting-case it's not useful
to assign "blame" until the sender has had sufficient time to learn
the available-forwarding-rate.

   Bottom line: a good start, Stuart!

---

From: Michael Welzl <[email-masked]>
Date: Tue, 1 Mar 2011 19:07:22 +0100

congestion definition, AGAIN? well, if you people think it's  
fun...   :-)

but check out some posts at:
http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-February/thread.html

and the introduction of RFC 6077.

---

From: Michael Welzl <[email-masked]>
Date: Tue, 1 Mar 2011 19:20:29 +0100

sorry - totally missed john's reference to that same thread in this  
very email  :)
anyway, we made quite an effort to get the text of rfc 6077 right, so  
i hope that this is really helpful at this point

---

From: John Leslie <[email-masked]>
Date: Tue, 1 Mar 2011 14:04:14 -0500

> i hope that this is really helpful at this point

   I do wish to commend Michael & Co. for RFC 6077, published this
February. They have done an excellent job.

   However, it is addressing "Congestion Control", which is not our
charge, and at 51 pages I can't expect everyone to be familiar with it.

   Our purpose is "Congestion Exposure" -- and IMHO we don't need to
"expose" exactly the same thing that "Congestion Control" folks set out
to control (were there even any such thing!).

   Some folks here think we're really closely tied to the ECN algorithm;
others don't. I don't know to what extent we need to discuss differences,
but I am willing to try to help delineate such differences (and possibly
even _resolve_ them ;^).

---

From: STUART VENTERS <[email-masked]>
Date: Tue, 1 Mar 2011 13:55:14 -0600

John,

I just looked up the ICCRG list. Thanks.
  There's a lot of similar stuff there.
    Some specific pointers below.

One def from ICCRG is as follows:

"A network  is said to be congested from the perspective of user i if the
utility of i decreases due to an increase in network load."

This combines the idea of congestion in the cloud with the user's congestion tolerance threshold.
   This definition seems to be heading towards congestion being the state that you are above or below some threshold.
   I think of congestion is a continuum of states of the cloud, separate from the user's idea of utility.
   Making it the result of a threshold test certainly raises issues of discontinuity.
   Making it dependant on differing users ideas of utility certainly makes it hard to define.
   I'm not sure which way the group wants to go, but at least this points out issues in need of consensus.

Incurring extra delay above the minimum is likely the first consequence a packet sees at the onset of congestion.
  This makes measuring delay or the amount of queuing delay a likely proxy for the amount of congestion in the network.
  One way to measure this proxy is to occasionally set bits or drop packets (ECN and RED?) when this happens.
  Another way is to measure the end to end delay for each packet with an accurate timestamps.
     This might require BGP work in the core to publish the minimum forwarding times,
       but perhaps no hop by hop consequences,
        except for finding a place for the timestamp in every packet.)
  I'm not sure if it matters if any of these actually measure congestion if the proxy tracks well enough.

I guess as the network gets more loaded, the next proxy is packet drops, which TCP depends on.
  If I understand the end goal here, we should never get this far over the cliff edge if CONEX works out.

I still vote for keeping the idea of congestion separate from the proxies.

As for the text I presented.
  I though about putting a disclaimer for the English.
    If I managed to get the idea on the table, I'm happy.
    If somebody can figure out a respectable way to say it, so much the better.
    On a second reading, "Congestion is when"? That's terrible, who write such a thing!  
  At least you'll got a little afternoon's entertainment.

Cheers,

Stuart

enc: interesting ICCRG pointers

URL for the above quote
http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-February/000034.html

A summary
http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-February/000035.html

Another discussion
http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-February/000052.html

The archive

-----Original Message-----
From: John Leslie [mailto:[email-masked]]
Sent: Tuesday, March 01, 2011 11:38 AM
To: STUART VENTERS
Cc: [email-masked]
Subject: "Congestion" definition

   But I digress...

---

From: "Mcdysan, David E" <[email-masked]>
Date: Wed, 2 Mar 2011 08:41:29 -0500

Hi Alissa,

The term (and document) in the context of the IETF 79 meeting minutes was
"mechanism," and I assumed that is what you meant in your post. Let me try
to map the discussion so far to your approaches using the above assumption.

IMHO, the agreement from IETF 79 was that use cases that can be proposed
for inclusion in the use cases document that do not necessarily need to
have a representation in the (current version) of the abstract mechanism
document. (Approach 2)

As posted by Toby and John, if a derivation from information provided by
the (current version) of the abstract mechanism can be defined to meet the
use case, then the use case document is the best place to document this.
(Approach 1)

Also, as I posted, if there is a use case that is not well supported by a
(derivation of) the abstract mechanism, then the use case document would
also be a good place to document this. (Approach 2)

Thanks,

Dave

---

From: "Mcdysan, David E" <[email-masked]>
Date: Wed, 2 Mar 2011 09:01:48 -0500

Hi Stuart,

An individual flow will experience the effect of loss or increased delay
if a shaper (more generally a non-work conserving scheduler) that is
similar to congestion of a shared resource. The current use case draft
only mentions congestion of a shared resources. This only covers a
(subset) of the things which both "feel" like congestion to a an
individual flow.  

IMHO, somehow the use case (and mechanism) draft need to describe and
address this shaper/non-work conserving scheduler case which will appear
as congestion to an individual flow. One simple way to address this would
be to declare it out of scope, but then in my opinion the wg has not
addressed an important use case that will be difficult to distinguish from
shared resource congestion.

Thanks,

Dave

On 3/1/11 11:56 AM, "STUART VENTERS" <[email-masked]> wrote:

>When a packet gets affected simply because a shaper or policer says that
>a specific flow or user is sending more bits that the traffic contract
>allows, 
>On the other hand, if the shaper were affecting packets because it sees
>the cloud is near or at congestion, then that effect feels like
>congestion.
>Under this definition, it might turn out that CONEX needs to expose both
>traffic management and congestion behaviors.
>  It would just be unfortunate if we had to muddy the definitions for the
>two in order to include the TM behaviors.
>
>
>Cheers,
>
>Stuart

---

From: STUART VENTERS <[email-masked]>
Date: Wed, 2 Mar 2011 11:09:11 -0600

Dave,

I support your direction
  (somehow, the use case draft needs to cover the shaper/non-work conserving scheduler)
     because it will get the issue on the table for discussion.

I'm just quibbling over the terminology.
   Congestion and shapers are similar in effect but different in cause and therefore response.
     For congestion, the optimal application response is send slower now and try faster later.
     For a shaper, the optimal application response is send slower now and somehow ask for better service if you need to go faster.
   I seems worth keeping the two separate in terminology for the time being.

Regards,

Stuart

-----Original Message-----
From: Mcdysan, David E [mailto:[email-masked]]
Sent: Wednesday, March 02, 2011 8:02 AM
To: STUART VENTERS; [email-masked]
Subject: Re: [conex] Discussion of new Use Cases pt 1

Hi Stuart,

Thanks,

Dave

---

From: "Toby Moncaster" <[email-masked]>
Date: Wed, 2 Mar 2011 17:24:50 -0000

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of STUART VENTERS
> Sent: 02 March 2011 17:09
> To: Mcdysan, David E
> Cc: [email-masked]
>      For a shaper, the optimal application response is send slower now
> and somehow ask for better service if you need to go faster.

Furthermore, the fact you have been shaped is not correlated with whether
you have had an adverse impact on other users. Consequently if you include
that form of congestion information in the ConEx signal then it needs to be
reacted to differently by the rest of the network...

My current instinct is that we should include of Dave's burstiness measure,
but give it its own section that looks at forms of congestion beyond the
classical queue-related congestion represented by packet drop, queue delay
and ECN marking. I guess that is what you are implying in the sentence
below...

> >   'Other packets' means either packets from other users or packets
> from
> >the same user.
> >
> >  I don't yet see the need for this, but could easily be persuaded by
> a
> >use case.

---

From: "Mcdysan, David E" <[email-masked]>
Date: Wed, 2 Mar 2011 12:58:44 -0500

Hi Stuart,

I agree  that although the user perceived effect is different, the cause
is important and the response may indeed be different. We need to document
this. There may be a need to distinguish how these are signaled as well.
For example, if loss is implicitly determined by the receiver then there
currently may not be a way to distinguish between congestion of a shared
queue and shaper buffer overflow.

Your last comment "somehow ask for better service if you need to go
faster" made me think of who would pay for making the service "go faster."
There is a burst mode service offered by some ISPs; and in some cases the
user pays and in others it involves recharging (i.e., someone else pays).

This reminds me of a comment as recorded in the Beijing minutes by an
unnamed person from Ericsson that recharging had been tried for 100 years
in telephony and it did not work and would not work in the Internet. I did
not have time to respond in the meeting, and am doing so here. Isn't toll
free service in telephony a form of recharging (i.e., called party pays
instead of caller)? Are you saying that toll-free service has not worked?
The assertion made by that speaker was that therefore recharging should
not be considered. I think that in at least the consideration of who pays
for adjusting the rate of a shaper that it is something to be mentioned.
Any disagreement?

Thanks,

Dave

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 2 Mar 2011 19:19:43 +0100

Hi,

> this. There may be a need to distinguish how these are signaled as well.
If you have a different element, giving you a different signal and you want a 
different response, isn't this simply a different mechanism and not ConEx??? 
When you talk about shaping that's not congestion and thus no case for 
Congestion Exposure.

> queue and shaper buffer overflow.
Loss is loss for the receiver... how can you distinguish how a packet got 
lost? And as you don't know how the packet got lost, you have to be 
conservative and assume its because of congestion.

This might be a quite radical view but it keeps thing more simple.

Mirja

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

---

From: "Mcdysan, David E" <[email-masked]>
Date: Wed, 2 Mar 2011 13:50:57 -0500

We have had a lot of good discussion on the list and I recommend that we
need to capture this in the working group use case draft.

I support adding a separate section in the use case draft to capture the
impact of non-work conserving schedulers (e.g., shapers, hierarchical
schedulers, etc.). This new section should include:
 * Discussion on the inequity of heavy versus light users motivation
(proposing text Toby sent out as starting point for this and related
technical points from the discussion)
 * Text describing burstiness as a potential measure (proposing text that
I sent 2/25 as starting point)
 * Add text that distinguishes between the current drafts' scope (shared
resource congestion) and individual congestion-like behavior (as proposed
by Stuart and Toby)
 * Add a placeholder for text to be developed (see Bobs' comment in
meeting minutes, Tobys' posts) that describes how the abstract mechanism
measures could be used to derive a "burstiness" or "heaviness" measure.

Unless I hear objections to developing text in a new, separate section, I
volunteer to do so.

Thanks,

Dave

---

From: STUART VENTERS <[email-masked]>
Date: Wed, 2 Mar 2011 14:04:29 -0600

Dave,

Not sure I understand the 3rd paragraph enough to agree or not.
   Perhaps a discussion about the psychology getting folks to part with their money would be a good subject for a beer BOF.

Hopefully, CONEX is more about making the service we already have work better.

Regards,

Stuart

-----Original Message-----
From: Mcdysan, David E [mailto:[email-masked]]
Sent: Wednesday, March 02, 2011 11:59 AM
To: STUART VENTERS
Cc: [email-masked]
Subject: Re: [conex] Discussion of new Use Cases pt 1

Hi Stuart,

Thanks,

Dave

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 2 Mar 2011 12:17:13 -0800

>   Bottom line: a good start, Stuart!

Two aspects of this definition strike me as needing refinement.

First, other packets come from other flows. Switches/routers do not
know what this "user" entity is.

Secondly the definition of "delay" is far too inclusive. It could be interpreted
as simply delay waiting for a round-robin turn at the transmitter.

QCN (802.1Qau) focuses strictly on queue depth (whether the queue is
actual or virtual). I think that is appropriate. The results of round-robin
algorithms are already felt in the queue depth, so there is no need to
separately measure them.

Queue depth is also easily measured. Combined with a delta measurment
the results give a very complete understanding of the network, and even the
delta can be measured inexpensively. Predicting delay caused by other
queues that share a given transmitter is fairly complex, and ultimately
unnecessary. The queue is either backing up (which can already be
measured) or it is not.

--
Caitlin Bestler
[email-masked]

--
Caitlin Bestler
[email-masked]
http://www.asomi.com/CaitlinBestlerResume.html

---

From: João Taveira Araújo <[email-masked]>
Date: Thu, 03 Mar 2011 14:23:00 +0900

To play devil's advocate here ....

> > and somehow ask for better service if you need to go faster.

Isn't a shaper just an induced bottleneck? I agree that it would be useful to know the nature of what is holding you back, but I don't think the response can be different unless you know very specific details of the shaper which would be outside the scope of ConEx (and have probably been pursued before).

> reacted to differently by the rest of the network...

Clearly you are having an adverse impact ... on the network's business model. Conflating all these causes into a single metric is not ideal, but I think it's a lot better than trying to fine-tune separate signals and risk using none (should checksum errors due to BER be treated as congestion?).  In the long term it seems simpler to provide a seemingly loose definition of what this single metric means than trying to very neatly compartmentalize what exists today. 

On a side note, a shaper in a conex setting should be much more readily identifiable than at present, and would probably be used more sparingly if congestion were used in addition to bandwidth to assess the quality of an ISP.

J.

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 3 Mar 2011 09:27:53 -0000

> Of João Taveira Araújo
> Sent: 03 March 2011 05:23
> To: conex
> > >    Congestion and shapers are similar in effect but different in
> cause
> > > and therefore response.
> > >      For congestion, the optimal application response is send
> slower
> > > now and try faster later.
> Isn't a shaper just an induced bottleneck? I agree that it would be
> useful to know the nature of what is holding you back, but I don't
> think the response can be different unless you know very specific
> details of the shaper which would be outside the scope of ConEx (and
> have probably been pursued before).

Indeed it is just an artificial bottleneck, so (depending on why it is
there) the best response is probably to try and get your rate to as close to
that rate as possible

> Clearly you are having an adverse impact ... on the network's business
> model. 

No, you may be being shaped to make sure you don't suffer loss on your DSL
link... Unless the UK is way out on a limb, ISPs seem to be moving beyond
imposing rate caps as part of their business model, instead relying on the
physical limits imposed by the access...

> Conflating all these causes into a single metric is not ideal,
> but I think it's a lot better than trying to fine-tune separate signals
> and risk using none (should checksum errors due to BER be treated as
> congestion?).  In the long term it seems simpler to provide a seemingly
> loose definition of what this single metric means than trying to very
> neatly compartmentalize what exists today.

I think the best approach is for the mechanism draft to focus on an
achievable measure of congestion but for the use cases draft to leave the
door open to future more complex (or just richer) measures... The one thing
I am desperate to avoid with ConEx is any further ossification of the
Internet (read "Why the Internet Only Just Works", M. Handley, BTTJ Vol 24,
No 3, July 2006)

> 
> On a side note, a shaper in a conex setting should be much more readily
> identifiable than at present, and would probably be used more sparingly
> if congestion were used in addition to bandwidth to assess the quality
> of an ISP.

Again, it depends on the type of shaper and what it is seeking to achieve. I
know that many UK ISPs throttle certain types of traffic at peak times,
regardless of whether they cause congestion, just because they believe they
are "heavy" users of the network. ConEx can certainly achieve a similar aim
in a far better manner.

Toby

> > >    I seems worth keeping the two separate in terminology for the
> time
> > > being.
> > >
> > > Regards,
> > >
> > > Stuart
> > >
> > > addressed an important use case that will be difficult to
> distinguish
> > > from
> > > >After thinking about Allissa and Dave's discussion, here's my 2c
> for a
> > > >CONEX congestion definition:
> > > >
> > > >
> > > >
> > > >
> > > >   'Adversely affected' means dropped or delayed more than the
> minimum
> > > >When a packet gets affected simply because a shaper or policer
> says
> > > that
> > > >    (Because traffic management is telling the user that there is,
> or
> > > >soon will be congestion.)
> > > >
> > > >
> > > >
> > > >The definition is focused on the discussion, so I may have
> completely
> > > >missed some other aspect of congestion?
> > > >
> > > >Under this definition, it might turn out that CONEX needs to
> expose
> > > both
> > > >  It would just be unfortunate if we had to muddy the definitions
> for
> > > the

---

From: "Mcdysan, David E" <[email-masked]>
Date: Thu, 3 Mar 2011 08:54:47 -0500

Hi Stuart,

A Beer BoF to discuss the 3rd paragraph sounds great to me, since the beer
in Prague is so good. :-)

In your opinion (and others in the working group who wish to comment), is
"somehow ask for better service if you need to go faster" about making the
service we already have (i.e., the shaper/ non-work conserving scheduler
rate) better? 

The choices (so far) seem to be:
 1. Treat the shaper queue the same as all other queues since they all
appear to create congestion as perceived by the flow user.
 2. Signal more information to the receiver about the cause of loss since
the remedy differs:
  A. For a shared queue, use current draft of abstract mechanism signals
to reduce load and choose packets for different treatments.
  B. For a queue dedicated to a receiver (e.g., shaper) signal information
that the shaper rate is the bottleneck, so that somehow (specific
mechanism not in the current conex wg charter) the user could make a
request to "go faster."

Thanks,

Dave

On 3/2/11 3:04 PM, "STUART VENTERS" <[email-masked]> wrote:

>   Perhaps a discussion about the psychology getting folks to part with
>their money would be a good subject for a beer BOF.
>
>>>Definition for the kind of congestion that CONEX is trying to expose in
>>>a
>>>statistically multiplexed routing cloud:
>>>

---

From: "Mcdysan, David E" <[email-masked]>
Date: Thu, 3 Mar 2011 09:03:08 -0500

Hi Caitlin,

I think that "queue depth" is another measure that could be considered and
is an example of measures other than those currently in the definitions
section of the use case draft and abstract mechanism draft (I.e., measures
based upon lost packets or those which are ECN marked).

LEDBAT proposes a measure that is related to queue depth of estimated
latency that is one that has been discussed on this list and raised some
questions as to how this would interact with conex.

It is not clear to me whether either of these measures could be derived
from the conex measures.

A possibility to consider would be to create a draft in iccrg to collect
the various definitions of congestion and use cases since conex has a
charter focused on near term deliverables?

Thanks,

Dave

---

From: "Mcdysan, David E" <[email-masked]>
Date: Thu, 3 Mar 2011 09:28:07 -0500

Hi,

A few responses in line below.

Thanks,

Dave

>Excerpts from Toby Moncaster's message of Wed Mar 02 17:24:50 UTC 2011:

Actually, I think these paragraphs were posted by Stuart Venters.

>useful to know the nature of what is holding you back, but I don't think
>the response can be different unless you know very specific details of
>the shaper which would be outside the scope of ConEx (and have probably
>been pursued before).

If anyone has pointer(s) to previous efforts to pursue this it would be
helpful.

>model. Conflating all these causes into a single metric is not ideal, but
>I think it's a lot better than trying to fine-tune separate signals and
>risk using none (should checksum errors due to BER be treated as
>congestion?).  

In the current use case and abstract mechanism draft checksum errors are
mapped to loss. This distinction could be important in a radio access
network. 

>In the long term it seems simpler to provide a seemingly loose definition
>of what this single metric means than trying to very neatly
>compartmentalize what exists today.
>
>if congestion were used in addition to bandwidth to assess the quality of
>an ISP.

This sounds interesting, but I don't completely follow this point. Could
you please elaborate.

>> > >After thinking about Allissa and Dave's discussion, here's my 2c for
>>a

---

From: "Mcdysan, David E" <[email-masked]>
Date: Thu, 3 Mar 2011 09:41:07 -0500

Hi Toby,

A few responses in line.

Dave

>physical limits imposed by the access...

In the US, rate tiers are a common ISP practice for higher speed physical
access networks (e.g., cable, FTTC, FTTH).

>are "heavy" users of the network. ConEx can certainly achieve a similar

Not all ISPs will have the same use cases, and some have other constraints
(e.g., regulatory). IMHO, assuming that the Internet is homogeneous and
the same everywhere is too simple of an assumption, and the use case draft
should capture the scenarios where conex can improve matters beyond the
status quo, such as the one Toby mentions above.

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 3 Mar 2011 15:57:59 +0000

>access networks (e.g., cable, FTTC, FTTH).

Definitely agree with Dave. In the US ISPs use rate tiers on wireline access (eg higher speeds for higher price tiers), although not as much with wireless access. I see service tiers in other countries as well, eg Sweden and Japan. Some US wireless providers charge different prices for access to different wireless technologies, eg "3G" vs "4G".

There may be different variations of "rate caps" in different geographies, though. In the UK, Plusnet appears to deploy "per-application rate caps" on a time of day basis. I don't think I've seen rate shaping like this in the US among the larger ISPs.

http://www.plus.net/support/broadband/speed_guide/download_speeds.shtml
http://www.plus.net/support/broadband/speed_guide/upload_speeds.shtml

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mcdysan, David E
Sent: Thursday, March 03, 2011 9:41 AM
To: Toby Moncaster; 'João Taveira Araújo'; 'conex'
Subject: Re: [conex] Discussion of new Use Cases pt 1

Hi Toby,

A few responses in line.

Dave

---

From: "Mcdysan, David E" <[email-masked]>
Date: Thu, 3 Mar 2011 11:05:15 -0500

Here is another link that summarizes rate and usage caps for US and Japan:

http://www.newamerica.net/files/Bandwidth%20Caps%20for%20High-Speed%20Inter
net%20in%20the%20U.S.%20and%20Japan.pdf

Dave

On 3/3/11 10:57 AM, "Woundy, Richard" <[email-masked]>
wrote:

>Definitely agree with Dave. In the US ISPs use rate tiers on wireline
>access (eg higher speeds for higher price tiers), although not as much
>with wireless access. I see service tiers in other countries as well, eg
>Sweden and Japan. Some US wireless providers charge different prices for
>access to different wireless technologies, eg "3G" vs "4G".
>
>There may be different variations of "rate caps" in different
>geographies, though. In the UK, Plusnet appears to deploy
>"per-application rate caps" on a time of day basis. I don't think I've
>seen rate shaping like this in the US among the larger ISPs.
>

---

From: STUART VENTERS <[email-masked]>
Date: Thu, 3 Mar 2011 11:36:24 -0600

Dave,

Yes, I was thinking that the optimal thing for a customer to do,
 when facing a limit from a traffic management shaper,
   was to change the service subscription parameters
     through either signaling or talking to a person.
This was probably not a useful direction for CONEX purposes
 except to highlight that there is a difference 
  between losses due to congestion
   and losses due to a traffic management shaper.

After sleeping on it, a more interesting difference is how others in the cloud are affected.
   If a user ignores losses due to congestion and continues sending, others are affected.
   If a user ignores losses due to a shaper enforcing his traffic contract and continues sending, only he is affected.

Maybe a key component in the definition for congestion causing behavior is that the behavior must affect others.

Regards,

Stuart

-----Original Message-----
From: Mcdysan, David E [mailto:[email-masked]]
Sent: Thursday, March 03, 2011 7:55 AM
To: [email-masked]; STUART VENTERS
Subject: Re: [conex] Discussion of new Use Cases pt 1

Hi Stuart,

Thanks,

Dave

---

From: "Mcdysan, David E" <[email-masked]>
Date: Thu, 3 Mar 2011 15:30:13 -0500

Hi Stuart,

Thanks,

Dave

On 3/3/11 12:36 PM, "STUART VENTERS" <[email-masked]> wrote:

>   If a user ignores losses due to a shaper enforcing his traffic
>contract and continues sending, only he is affected.

However, since loss (is usually)implicitly determined, there is no (easy)
way for the current conex abstract mechanism proposal to tell the
difference between these cases. A question I have for the experts on the
abstract mechanism and the associated mechanism is a high-level analysis
and explanation as to whether this distinction has no impact or makes a
substantial difference.

>is that the behavior must affect others.

A statement to this effect is already in the first paragraph of section 4
of the use-case draft:

We argue that current traffic-control mechanisms seek to control the
   wrong quantity.  What matters in the network is neither the volume of
   traffic nor the rate of traffic: it is the contribution to congestion
   over time -- congestion means that your traffic impacts other users,
   and conversely that their traffic impacts you.  So if there is no
   congestion there need not be any restriction on the amount a user can
   send; restrictions only need to apply when others are sending traffic
   such that there is congestion.

The intent of the first sentence may be to assume that there are no
traffic-control mechanisms in place (e.g., shaping as described in this
thread which is not (yet) described in section 3.1 as an existing
approach). Would look to the authors to clarify the intent.

However, as mentioned on this thread shaping is deployed in a number of
ISPs in some countries. Seems like the draft  should describe a use case
where shaping is present.

---

From: John Leslie <[email-masked]>
Date: Thu, 3 Mar 2011 16:01:40 -0500

> know what this "user" entity is.

   Agreed.

> Secondly the definition of "delay" is far too inclusive. It could be
> interpreted as simply delay waiting for a round-robin turn at the
> transmitter.

   Agreed.

> actual or virtual). I think that is appropriate. The results of
> round-robin algorithms are already felt in the queue depth, so there
> is no need to separately measure them.

   Queue depth, IMHO, is a better measure than most things available
to us.

> the results give a very complete understanding of the network, and
> even the delta can be measured inexpensively. Predicting delay caused
> by other queues that share a given transmitter is fairly complex, and
> ultimately unnecessary. The queue is either backing up (which can
> already be measured) or it is not.

   I agree with all of this, but...

   "The light's much better over here!" ;^)

   Can Caitlin (or anyone else) come up with a way to deploy this
throughout enough of the Internet?

   Or, is the bottom-line that we can't design a single Experimental
protocol?

---

From: "Toby Moncaster" <[email-masked]>
Date: Fri, 4 Mar 2011 09:42:00 -0000

> Of John Leslie
> Sent: 03 March 2011 21:02
> To: Caitlin Bestler
> Cc: [email-masked]
> Subject: Re: [conex] "Congestion" definition
> 

So the beter wording would be to remove "'Other packets' means either
packets from other users or packets from the same user." And then insert
"..., whatever their source, ..." after "caused by other packets..." in the
first sentence

> > interpreted as simply delay waiting for a round-robin turn at the

I think one could get locked into an endless debate here about sources of
delay...

>    Queue depth, IMHO, is a better measure than most things available

And queue depth is effectively what ECN tries to encode, albeit in a
slightly odd manner...

>    Or, is the bottom-line that we can't design a single Experimental

I don't think designing them is the problem. Deploying them might be an
issue though ;)