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

[Mikael Abrahamsson <[e-mail]>]

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? 
And how would it work when it's connected to an ISP<->ISP peering port?

>   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.

>> 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.

>> 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.

>   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.

>> 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.

>   In principle, an ISP could entirely avoid congestion of the first: in 
> practice, most come "close enough". But for the second, it's quite 
> impossible to avoid congestion _under_some_conditions_ where the 
> receiving customer is "offered" traffic (often from diverse sources) 
> greater than his link can handle.

An ISP can certainly try, and I don't agree that this is "impossible". Of 
course the congestion will be destination/flow-dependent, but this is 
something that has to be taken into account.

>   The receiver already has the information on incoming congestion
> without ConEx. The sender _would_ have an additional signal from
> ConEx; but it's unlikely it will tell him much about outgoing
> congestion _within_ his ISP's control.

Well, even if the information is already available, it's not exposed to 
the user.

>   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.

>   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.

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.

Let me describe a typical home access scenario to visualise what I'm 
trying to say:

The host IP stack is sending 5 different TCP flows. The IP stack is 
dumping these packets into an egress Wifi NIC FIFO buffer, which is 
emptied by the Wifi hardware as packets are being passed out the wifi air 
interface. When there is a 20ms stop in the wifi communication, this 
affects all flows, and the FIFO buffer might be quite big. When it arrives 
in the wifi router, it's now going to split up the traffic because one 
flow was going to the ethernet attached file server, and 4 was going out 
the ADSL interface. The ethernet is faster than the wifi, so the stupid 
FIFO buffering here doesn't matter, but the ADSL interface is an ATM FIFO 
single PVC again, with quite large buffer, so this can easily reach 
hundreds of milliseconds of buffering when this is full. Even if the IP 
stack might do AQM, the cell buffer is so big that the AQM empties into a 
10-20ms cell FIFO anyway, so the AQM is crippled even if it exists. Now we 
enter the DSLAM and it might have a 100 meg ethernet upstream interface, 
and you now have many hundreds of customers on this 100 meg interface 
which means it's full, but it's a L2 switch interface and it only has 5 ms 
of FIFO buffers with tail drop so it'll just drop 100% of packets at a 
certain queue depth. After this we hit a 1G router interface with 600ms 
FIFO, where if it's full, you'll get a lot of delay, often without any 
drops because most TCP flows will never reach full queue depth before the 
bandwidth/delay product is larger than available TCP window.

Phew, that was a lot of text. Anyhow, it was just an example of all the 
different places where packets can be dropped/queued in the network and 
how they might work today, and I believe there are a LOT to be done to 
improve how all these different queue points can handle traffic to give 
the end user a better network experience. This is both within the home and 
within the ISP network.

-- 
Mikael Abrahamsson    email: [e-mail]