Subject: [conex] Additional responses to draft-mcdysan-conex-other-usecases-00

From: Bob Briscoe <[email-masked]>
Date: Tue, 09 Nov 2010 06:45:42 +0800

David,

My main review comments were similar to Alissa's and Toby's. So I'll 
pitch in to their thread where I differ slightly, but otherwise I'm 
just nodding.

But, rather than make that thread too complicated, I've added a few 
different points here in a separate thread.

First, I want to say it was really good to get your angle on this. Thank you.

#/ Don't mention congestion pricing?

Some of your use-cases might fall foul of the constraint in the ConEx 
charter that says:
"Congestion-based billing is not within the scope of the WG"

I was happy to go along with that charter constraint, because I don't 
think any ISP would want to do congestion-based billing anyway - 
certainly not at the retail level.

But how do you read this charter constraint? I read it as we 
shouldn't work on mechanisms to actually *do* congestion-based 
billing. Do you think it's OK to talk about it as a use-case, 
particularly at the wholesale level between operators?

#/ Heavy user = heavy volume, or heavy congestion-volume?

Once an operator has visibility of congestion-volume, won't they 
define a heavy users by congestion-volume, not volume? That's the 
whole point of the use-case encouraging LEDBAT-like transports. Won't 
an ISP be willing to allow their users to transfer as much as they 
want, as long as their transport jumps out the way whenever there's 
the slightest sign of congestion?

Put another way, once you have a metric for the incremental cost of 
one user's traffic on others, limiting volume irrespective of cost 
could be construed as arbitrary discrimination against high volume 
users who are being careful to cost very little.

Sure, absent ConEx, volume is a (poor) proxy for congestion-volume. 
But once we have ConEx, the landscape changes.

==Metrics==

#/ Congestion-volume does automatically what the other metrics try to do.

I'm not sure whether the text in 4.1 is saying we need more than 
ConEx or it's saying ConEx should do all this.

I've got a lot more to say about the metrics you have suggested, but 
manyana - I need to get to bed...

==Misconceptions==

#/ You've cited me as saying "...it's complex for users to manage 
their activity to control the price they pay..." I don't think I said 
that, because I don't really agree.
* First, it's enough for users to just do what they want to do, and 
if their bill gets too high for them, they tend to do less, just like 
in other walks of life.
* Second, I believe minimising congestion can all be delegated to 
their machine (just as TCP attempts to now), so no problem there.

#/ 3rd bullet in 4.2:

This talks about feedback from the network being more important if 
some form of congestion pricing is in force (I guess you include 
congestion policing in that?)

The very subtle but important idea behind re-ECN (and hopefully 
ConEx) is that the accounting metric is wholly controlled by the 
sender. The provider makes the sender accountable for the congestion 
the sender says it expects it will cause, NOT the congestion that 
actually happened once packets have been through the network.

If the sender gets feedback from the receiver about a sudden increase 
in congestion, it can just stop sending packets, and not send any 
more ConEx markings either (if it is limited to an allowance, it will 
not draw down any more). But if the sender wants to continue (as it 
usually will), it has to be accountable for the congestion it just 
contributed to by re-echoing that amount of ConEx markings. If it's 
using something like TCP, of course it will also go slower, so as to 
avoid the congestion continuing.

So, there is full transparency. The network doesn't need to give the 
source any more feedback about congestion than it already does on the 
forwaard path (ie by dropping stuff). But the ConEx audit function 
incentivises the source to get accurate timely e2e feedback from the 
receiver (which most transports already do, of course).

So yes, feedback from the network is important, but no more is needed 
for ConEx than we already have. ConEx is about adding feedback from 
source to network, which is where TCP/IP is deficient.

#/ Not counting (last para of 4.2)

That's an important item to mention. There might be cases where the 
operator has flunked and needs to tell the user that they will get a 
congestion rebate or something. I don't think this should be done in 
real-time (by telling the user "I'm not counting congestion at the 
mo"), which could lead to congestion-collapse. But, there might need 
to be a later refill of the customer's allowance, perhaps after a 
capacity outage, where the operator wants to apologise not punish its users.

This generally falls into the category of customer <-> 
traffic-management-node interface. I don't think it's in ConEx scope 
to define these standards, but we should certainly add our voice to 
those wanting to define them (e.g. Dave Oran).

More later...

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: "Mcdysan, David E" <[email-masked]>
Date: Mon, 8 Nov 2010 20:16:14 -0500

Hi Bob,

Thanks for the review and comments.

Some responses in line below prefixed by DM.

Regards,

Dave

________________________________________
From: Bob Briscoe [[email-masked]]
Sent: Monday, November 08, 2010 5:45 PM
To: Mcdysan, David E
Cc: ConEx IETF list
Subject: Additional responses to draft-mcdysan-conex-other-usecases-00

David,

DM - I would not want to preclude this use case, and tried to give several examples in my draft. I viewed a number of the talks in the technical plenary as dealing with "congestion pricing" at the retail level (either directly to an end user of via recharging).

billing. 

DM - Good question. I read the charter as that actual protocols and message exchanges to *do* billing were out of scope, but that usage information which could be used as inputs to such billing was in scope. Would be good to clarify this point.

Do you think it's OK to talk about it as a use-case,
particularly at the wholesale level between operators?

DM - As discussed some on the list, I don't think there is consensus that inter-operator settlements is something all operators want to do, but I would certainly want to include it (e.g., for at least recharging), as well as some forms of congestion oriented usage collection at the retail level.

DM - I think the use case you describe is already well described in the moncaster draft. I tried to further describe the "burstiness" mechanism that I had in mind in my response to John Leslie.

DM - What I see as an issue with this method is the unpredictability of this as seen from the user perspective. A user could engage in similar behavior and in one instance see no congestion but in another see a great deal of congestion. This arises from an (unachievable expectation) that a fixed bandwidth tier is a guarantee to send at that rate for an indefinite period of time when in fact statistical multiplexing is being used.

==Metrics==

DM - Please review my response to John. 

==Misconceptions==

DM - My apologies, I cited Varian and your statement from the Maastricht technical plenary
"but unpredictability of congestion billing is unpopular" 

Can certainly remove your talk as a reference or reword if this text along these lines is to be included in a wg doc.

DM - That is a possible use case, but the one I had in mind is the one is more like the one that Toby described
 as helping users avoid "surprises" at the end of the month, as he said that currently some wireless providers use. Here I had in mind the congestible resource being the monthly usage tier.

#/ 3rd bullet in 4.2:

DM - I think policing is a use case already covered in the moncaster draft. 

DM - If policing is a form of pricing, then the charter issue of billing you mentioned earlier may be relevant here. I viewed "policing" as a form of traffic management as stated in the wg charter. The classification of policing is an area I think the wg should discuss/agree. I view policing as more of a reaction in the event that other mechanisms have not worked and not as a usual mode of operation, it can create unpredictability and potentially cause user complaints as voice by others on the list and in the Maastricht plenary.

DM - Thanks for the summary. I think that I understand the use case that is the focus of the moncaster draft as congestion occurring in a work conserving scheduler at queues at various points in the network. The principal idea in my draft is that there are other congestible resource use cases for which feedback can be useful, a non-work conserving user-facing shaper, a long time period (e.g., monthly) usage counting tier, historical (as modulated by actual congestion using a method you summarized above) utilization for time of day/week, and recharging indications to a sender.

DM - Good customer service is always desirable, and I think such a means is worthwhile. Would be interested in hearing more about this.

More later...

Bob