Ian McDonald wrote:
On 3/23/06, Mark Butler <[EMAIL PROTECTED]> wrote:
I understand that timed intervals between individual packets is not
realistic in general. What I have in mind is a fixed granularity
transmission timer, where packets are assigned to buckets, and
transmitted one bucket per timer expiration.
Why is it not realistic?
I mean not realistic as a general practice. It is certainly realistic
at low to moderate bandwidths, or higher ones when you can pay the price
in cpu overhead. At some point one has to start coalescing packets into
transmission groups, if anything else is going to run on the system.
>From a protocol design point of view, the main question is which is
more expensive, rate based timer expiration, or generating ACKs at a
high enough rate to self clock. With 1 Gb/sec reliable transport
protocol, every other packet ACK generation, and Ethernet MTU size
packets, ACKs are generated every 30 usec on average. With Van Jacobsen
style pre-queuing a large percentage of them are wasted overhead,
because a long series of them accumulate in the prequeue before the
receiving thread is activated.
Various others look at doing things like certain number of ACKs per
RTT rather than per packet or fixed number of packets.
For both using interpacket intervals and differing ACK strategies have
a look at TFRC:
http://www.icir.org/tfrc/
This seems to work quite well for me in all the testing I've done
although I have only tested up to 100 Mbits - but this tested OK on
500 MHz machines so newer machines should handle faster rates well.
What I am suggesting (hypothetically at least), is a scheme where
transport protocols deliver flowlets consisting of a series of packets,
optimal start time, start time tolerance, optimal interpacket interval,
and jitter tolerance to special purpose queuing disciplines. The
qdiscs (or equivalent) would assign packets to transmission buckets
using the specified parameters, creating new buckets or sharing existing
ones as appropriate.
There should be two basic types of buckets - buckets for real time
traffic and buckets for non-real time traffic. If a timer expiration is
missed under load, packets in the corresponding bucket(s) past deadlines
would be dropped. Remaining real time packets from a missed real time
bucket would be transmitted in order. Non-real time traffic, however,
would slide in an interval preserving manner, roughly one timer interval
at a time (subject to eventual expiration).
The qdiscs would ideally exist at the layer 2 / layer 3 boundary like
existing qdiscs, but the problem is getting the scheduling parameters
down that far. Perhaps a transport protocol could create a tagged route
entry with the appropriate parameters, the routing layer could assign
skbs to it by flow tag, and the qdisc could refer to the route entry and
some sort of skb sequence number to derive the appropriate scheduling
information.
- Mark
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
