On Wed, Jan 27, 2021 at 2:14 AM David Laight <David.Laight@xxxxxxxxxx> wrote: > > If I read this correctly it adds a (potentially big) queue between the > LAPB code that adds the sequence numbers to the frames and the hardware > that actually sends them. Yes. The actual number of outgoing LAPB frames being queued depends on how long the hardware driver stays in the TX busy state, and is limited by the LAPB sending window. > IIRC [1] there is a general expectation that the NR in a transmitted frame > will be the same as the last received NS unless acks are being delayed > for flow control reasons. > > You definitely want to be able to ack a received frame while transmitting > back-to-back I-frames. > > This really means that you only want 2 frames in the hardware driver. > The one being transmitted and the next one - so it gets sent with a > shared flag. > There is no point sending an RR unless the hardware link is actually idle. If I understand correctly, what you mean is that the frames sent on the wire should reflect the most up-to-date status of what is received from the wire, so queueing outgoing LAPB frames is not appropriate. But this would require us to deal with the "TX busy" issue in the LAPB module. This is (as I said) not easy to do. I currently can't think of a good way of doing this. Instead, we can think of the TX queue as part of the "wire". We can think of the wire as long and having a little higher latency. I believe the LAPB protocol has no problem in handling long wires. What do you think?
