[MLB-WIRELESS] Packet scheduling [aka: What do people want todowith the wirele ss connection?]

[Daniel Pittman]

On Wed, 14 Nov 2001, Richard Nelson wrote:
> Daniel Pittman wrote:
>> On Tue, 13 Nov 2001, Richard Nelson wrote:
>> > Daniel Pittman wrote:
>> >> On Tue, 13 Nov 2001, Tyson Clugg wrote:

[...]

>> That's the real problem. You need a coherent policy across the entire
>> network, not to mention support for the queue policies on all routing
>> nodes[2] in the tree...
> 
> Exactly. There are some new experimental kinds of QoS that do not have
> these requirements that might suit a collaborative/experimental type
> network. 

True, and a community network might well be happy with some-but-not-all
nodes supporting QOS assurance. After all, you care more about the links
you actually use than those that you don't...

> Internet 2 have started a Scavenger Service, a sort of less than best
> effort service. 

Looks interesting. I will hunt at it a bit more. :)

[...]

>> Ah, cool. That's nice. I wondered if the silly limit on classes that
>> the TOS implementation had would go away. So, there are a set of well
>> defined classes in there already, such that you could just use the
>> standard diffserv classes on a network?

[...]

> I don't think the limitations of the TOS flags definition was really
> the small number of classes available. 

Well, it's a limitation from my point of view; I want more than three
classes. OTOH, I live without any, so it's not all /that/ important.

> I suspect that running more than three or so classes on a network
> would lead to horrific complexity . 

It may well; I haven't tried that sort of thing on a large network.

> It was more a case that there was no consistant definition of what the
> flags actually meant and how they should be implemented. 

Hrm? My reading of the RFC on TCP and IP strongly suggested otherwise.
The meaning was fairly clear -- if you can, optimize for low cost of
transmission, low latency transmission or high bandwidth transmission.

> The TOS bits were individual flags that could be set independently and
> then they conflicted, 

Er, no. At least, not according to my memory. Maybe the early RFC
documentation let that happen, but it was certainly /not/ the case
later: you got to chose *one* thing. :)

> I think from memory that if they were all set you had a completely
> circular definition. 

Well, yes. They were, so far as I can tell, a hint as to which otherwise
equivalent route to send a packet on, with the intent of only one being
set at a time. I would need to check the documents to verify that,
though...

> Anyway, with diffserv there are some reasonably well defined
> implementation recommendations, CBQ and RED mainly.

I don't like RED on anything that even approximates a high speed link;
what I have seen of it suggests that it manages to have the same
unfairness issues that TCP has with the startup of interactive (low
latency, low bandwidth) sessions while a bulk transfer is running.

CBQ is interesting, but not something I know that much about. IIRC, the
Linux implementation has some vagueness in some of the measures that
make it less accurate than one might home.