Also, at the NSF meeting Jonathan Smith put up a nice graphic that argued
that as you move towards the core of the network, you have higher speeds
and you need more aggregation of flows and less processing per flow.
This kicked an idea into my head about "SONET switching". Recall that
SONET packets increase in size as speeds increase, so that the frame
takes the same amount of time on all wires. Suppose when we
reach a faster link, we aggregate packets into the SONET frame not
just based on the next hop, but based on the entire path it will
take while on fast links. Each packet in a SONET frame has the
same route through the "fast cloud", and only peels off as it
exits the cloud. (Currently, the packets in a SONET frame are
demultiplexed and re-multiplexed at every router.)
The analogy here is with European train operation, where the same
high speed train has cars for each of its destinations, which
peel off as needed for the slower last hop.
OK, now combine these two ideas. The key to handling high speeds
and small buffers is aggregation of flows into more manageable units.
This is true no matter what control loop you are using: drops, ECN,
rates, or credits. Hence duality (or multiality if you prefer).
Aggregation is easy for rates; each flow has a rate, and they just add
when put together. To reduce the rate of an aggregate flow, you just send
an upstream message, which can be split among whatever flows are feeding
into the aggregate flow.
Ditto for ECN. Assuming symmetric paths, the backwards ECN packet
could have the bottleneck link in it, signalling all upstream flows
to reduce their rates and/or avoid the congested part of the network.
We've talked about this.
Drops are harder but still feasible. The upstream routers
have to look at TCP ack patterns to detect a drop on a flow, and
then eagerly drop packets from other flows to slow them down.
Each router has to only drop a few packets for every input link,
rather than a few packets for every input flow. And we've talked about
this.
And ditto for credits. Up to now, credits haven't been easily
aggregatable, since if you have one slow flow aggregated into
a bunch of faster flows, the slow one will chew up all the buffer
space, keeping the faster flows from flowing. Hence the appeal
of per-flow buffering with credits. But the aggregate buffer space is a
problem at high speeds, as is the processing cost. But if the upstream
router schedules packets into the aggregate flow based on how fast each
flow is flowing, then the fast intermediate routers can just deal with
credits on the aggregate flow, and not worry about the individual flows.
The effect is pretty much the same as the Kung model of assign buffers
to each flow based on measured throughput rate, but is easier
to implement and to reason about.
Bottom line is that if you start applying the systematic principle
of aggregation, all these solutions (with their apparent individual
strengths and weaknesses) start looking identical.
tom