>>>>> "jamal" == jamal <hadi@cyberus.ca> writes:
[...]
Nice introduction!
jamal> The driver uses the feedback information to intelligently
jamal> adjust its sending rate. (i.e reduce or increase calls to
jamal> netif_rx() or send a congestion-experienced frame to its
jamal> peer eg in X.25). In the sample tulip driver, dynamic
Just a clarification (for the next version ;): it´s not really a
congestion notification. It is just a `receiver' busy condition.
LAPB is not designed for congestable links and cannot really report
that congestion occured. It can only delay acknowledgement (and
communicate rx_busy state to the peer). The retransmission was really
only designed for occasionally recovering from transmission error
caused by line noise. Once a packet has been lost, all packets (even
those already arrived after the lost one) must be retransmitted. There is
nothing like selcetive acknolegment. Thus, although LAPB can recover from
packet loss caused by congestion, it will not react in a manner adapted
to the congestion state. For minimizing possible confusion about the
different X.25 layers, I´d suggest to eplicitly call it `LAPB
datalink layer of X.25´ in future versions of the document.
jamal> I have experimented with two schemes: one which samples the
jamal> queue via a timer and one which does it per-packet and
jamal> found that the per-packet sampler gave better results (more
jamal> samples, Shannon's theorem applies). It didnt matter
jamal> whether HZ was 100 or 1024 during the tests. The measure
jamal> of "better" was throughput.
Nice. I think such a kind of fair input queueing would be an important
features because that allows to offer a highly reliable netif() to
slow links which are slow, but inefficient to handle congestion
(like X.25 LAPB datalink protocol). Network interfaces could trade
reliablilty for speed.
Another issue: Some protocols designed for congestable links support
forward and/or backward congestion notification (e.g. frame relay, I thing
DECnet and IPV6 also can do so). Thus, it would be nice if those protocols
could easily access the congestion state such that congestion notification
bits can be set efficiently.
[...]
Seems there are lots of interesting problems to investigate and
to solve. Anyhow, no matter how the details will be in future,
What´s basically needed is a return value for netif_rx(). This is also
`nice` for symmetry reasons (in 2.4.x, dev_queue_xmit() returns an
int, too).
Would it possibe to make the return sematics of the varios
layer-boundary-crossing methods conssitent ore are they just to
different? There is currently no agreement among the different
protocol implementations. Many of them use a boolean return value for
reporting whether delivering to upper/lower layer was sucessful.
But there is unfortunatly no unique convention whether 1 means success
or failure.
I´ll be leaving for Linux-Kongress. Thus, I won´t be able to
further contribute to this thread for this week.
Cheers,
Henner
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:21 EST