Re: [conex] New concepts text in draft-ietf-conex-concepts-uses

[John Leslie <[e-mail]>]

Mikael Abrahamsson <[e-mail]> wrote:
> On Tue, 19 Jul 2011, John Leslie wrote:
> 
>> But if an ingress policer is close enough to the source it needn't be 
>> flow-aware -- the user is in the best position to balance demands of 
>> different flows, and the policer merely needs to enforce an overall 
>> limit.
> 
> I don't see the need for anything more than we have today then? What would 
> a conex enabled policer give if it's one policer per access port anyway? 

   It would likely drop packets which exceed the Congestion-Expected
allowance. (This is by no means the only possibility, but it seems the
most likely.)

> And how would it work when it's connected to an ISP<->ISP peering port?

   It would likely drop packets which exceed the Congestion-Expected
allowance. (Here other options seem less unlikely...)

>> If, OTOH, various users are aggregated before the ingress policer,
>> the ingress policer is in a very poor position to sort them out --
>> especially with forging of source addresses being so easy. I think we're
>> wasting our time to try.
> 
> I always thought the policer acted on aggregation ports, ie for several 
> users.

   That is an implementation choice. There are setups where you can be
quite confident which customer sent you the packet without depending on
source address. And there are situations in which trusting the source
address is reasonable. But IMHO, trying to distinguish flows would be
a poor practice. YMMV, of course...

>>> Show congestion to everybody, the user and ISP alike.
>>
>> Do you mean something beyond simply having in the IP packet in a
>> well-known place? If so, what?
> 
> I'm talking the congestion signals (re-ECN etc) that seems to be the 
> centarl goal of ConEx.

   They, by definition, will be in a well-known place in the packet.

>>> I would like to see it also differentiate between self-congestion
>>> (access link) and shared-link congestion (everything else than the
>>> access link), but I have no idea how to do this.
>>
>> Neither do I... nor do I see any benefit. At any point, it's trivial
>> to distinguish upstream from downstream.
> 
> There is tremendous benefit from differentiating "my access link is 
> congesting because *I* am using it" to "my ISP doesn't have enough 
> capacity so because of *others* I can't use my full access speed", for
> the user point of view.

   I can't think of a way to do that without cooperation by your ISP.
However, the likes of DSLreports ought to be able to estimate congestion
within your ISP...

>> Oh, but we do. Any congestion on the return-path from receiver to
>> sender is Somebody-Else's-Problem.
> 
> I don't agree at all. If someone is dropping the traffic I'm about to 
> receive, I want to know about it.

   I think we have a failure-t'communicate here. Any transport receiver
has to signal back to the sender, which may follow a congested path as
well. How this is done is not a problem for ConEx to solve.

>>> Should we give guidance to how the IP stack should expose this
>>> information to the user?
>>
>> I don't understand the question.
> 
> I want to empower the user with knowledge about congestion. I thought 
> this was a central goal of ConEx, to *expose* congestion.

   ... to the network layer: the application layer is awfully far removed
from that...

<snip>
> 
>> Do you have suggestions on what would help?
> 
> So, for core links, my suggestion is to use WRED and drop/set ECN at a 
> certain queue depth, for instance 20-30 ms queue depth. For access links, 
> I'd like to see "fair queuing" (RFC970) enabled on a lot more ADSL/cable 
> modems/Wifi routers, and also in hosts.
> 
> RFC1254 also lists different ways of handling this. Generally, I'd say not 
> much of this is actually in use on the Internet today, 25+ years later :P 
> I run fair-queue on my access link at home, it works great.

   These seem reasonable, but not for ConEx to say...

>> Ah, yes. Buffer tuning is fairly well understood by ISPs, but the 
>> distribution-of-information channels don't work well. :^( If you
>> think ConEx could help, please say how!
> 
> Er, considering basically NONE of the typical CPEs in use today does 
> anything other than FIFO with a lot of buffers, I'd say if the ISP 
> understands bufferbloat, they haven't communicated this to the purchasing 
> department who controls CPE purchases, because if they did, the typical 
> ADSL router would do better things than FIFO for upstream buffer 
> management.

   As I said, distribution-of-information channels don't work well. :^(

> So I would like to have ConEx describe how buffering should be implemented 
> in all devices who might experience congestion on the outgoing interface 
> (hosts and routers, most likely different advice, ConEx perhaps should 
> define different classes of devices that should do different things), this 
> should be very good guidance going forward.

   Hmm... I don't see where that fits in our current documents. Perhaps
you'd like to try writing an Internet Draft?

--
John Leslie <[e-mail]>