[e2e] Question the other way round:

[Detlef Bosau]

Jon,

I'm with you in most points, particularly with respect to wireless
networks ware a "rate" is hardly predictable.

Particularly in wireless networks, we are interested in high link
utilization. (The German translation of Ephesians, 5, 16 would fit in
here, for German speaking readers: "Kaufet die Zeit aus, denn es ist
böse Zeit.") So we often use opportunistic scheduling: The channel is
granted to sources which are likely to see a good throughput, while
others are postponed.  Actually, this makes wireless networks affordable
at all.

On the other hand, a strict work conservation may lead to unwanted
effects in large BDP networks  - particularly when the tail wags the dog
and it is up to the application to keep the line busy.

I had a discussion with Martin Geddes about this matter where Martin put
a strong emphasis on the avoidance of work in progress, so buffers
should stay empty under all circumstances. This is exactly an uneconomic
way for lines with variable and unpredictable throughput (or more
generally spoken for expensive machinery particularly with expensive
set-up times, e.g. a furnace or a production line for cars) (I once
attended a talk by Hans Reiser, who then talked about Adam Smith, I
shouldn't, so I leave economics here).

On the other hand I think of large BDP networks, where the capacity (and
hence the sojourn time) is DOUBLED by buffers, for the only reason that
the line is fully utilized by a flow's actual workload even when the
workload reaches its lower limit in the "congestion sawtooth". And I
don't see a compelling reason for doing so. When the line is utilized
that's fine. And it is (again economic thinking) up to the provider to
find an appropriate match of offer and demand here. (Underutilization is
expensive, overload causes waiting times.)

In my opinion, this should be a reason for well designed scheduling -
which may well pursue different objectives for different lines.

Simply doubling a lines "capacity" by buffers (large BDP lines) is
questionable. A simple round robin scheduler would do better. More than
that: It would spare us these annoying probing activities which we tried
to overcome with BIC and the like. And which lead to the mice elephant
problem where elephants outperform mice.

That doesn't mean that self clocking and self scheduling, as done in
TCP, is generally bad.

But that should say that, depending on the scenario, there may be
alternatives which are more appropriate. And with particular respect to
the e2e consideration in Salzer's paper: I think indeed that the actual
scheduling strategy for a link should be chosen locally and not on the
end points.



Am 17.11.2013 21:41, schrieb Jon Crowcroft:
> indeed....
>
> perfect schedules would work for fixed rate traffic...but in the age of
> data nets (eve with packet video and audio) we decided to go with
> statistical multiplexing and work conserving, so we keep links busy
> whenever packets arrive but we don't know when packets will arrive so we
> have to approximate as best we can to having packets arrive when there's
> just enough capacity on an output link for the current input flow rate at
> any switch so in some sense there's either 0 or 1 packet ahead - in the
> fluid flow approximation world, you get infinitesimal slices of packets, so
> you can adjust your flow rate to be nearer  a perfect fit - in the discrete
> packet world, you are off by edge-of-packet's worth at least - but worse,
> the traffic matrix variation over time (and in the presence of wireless and
> mobile wibbly wobbly links, the actual output link capacity) vary
> unpredictably with time, so your estimates of what you can do are off by as
> much as an RTT's worth of  lumpy squeezy stuff (going for R rather than D)-
> of course if a lot of sources last a really long time, and the number of
> them doesn't vary, and they are all application limited,you might do very
> well (i.e. go for D rather than R)
>
> seems ok to me

-- 
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30   
70565 Stuttgart                            Tel.:   +49 711 5208031
                                           mobile: +49 172 6819937
                                           skype:     detlef.bosau
                                           ICQ:          566129673
detlef.bosau at web.de                     http://www.detlef-bosau.de