No subject

--- begin extract ---
4.3.  Out-of-sequence Packets

Occasionally packets lose their sequencing across a complicated
internetwork.  Say, for example that a PNS sends packets 0 to 5 to a
PAC.  Because of rerouting in the internetwork, packet 4 arrives at the
PAC before packet 3. The PAC acknowledges packet 4, and may assume
packet 3 is lost. This acknowledgment grants window credit beyond packet
4.

When the PAC does receive packet 3, it MUST not attempt to transmit it
to the corresponding PPP client.  To do so could cause problems, as
proper PPP protocol operation is premised upon receiving packets in
sequence.  PPP does properly deal with the loss of packets, but not with
reordering so out of sequence packets between the PNS and PAC MUST be
silently discarded, or they may be reordered by the receiver.  When
packet 5 comes in,packet 5 comes in, it is acknowledged by the PAC since it has a higher
sequence number than 4, which was the last highest packet acknowledged
by the PAC.  Packets with duplicate sequence numbers should never occur
since the PAC and PNS never retransmit GRE packets.  A robust
implementation will silently discard duplicate GRE packets, should it
receive any.
 it is acknowledged by the PAC since it has a higher
sequence number than 4, which was the last highest packet acknowledged
by the PAC.  Packets with duplicate sequence numbers should never occur
since the PAC and PNS never retransmit GRE packets.  A robust
implementation will silently discard duplicate GRE packets, should it
receive any.
--- end extract ---

So we could implement re-ordering with some kind of adaptive time-out but
this is currently beyond what PoPToP does.
         
Possibly your problem is more that we don't implement any kind of congestion
control, etc, etc - I haven't worked on this since I basically have no use
for it (all my 'clients' - the students - are on a minimum of 10Mbps ethernet,
at a maximum of 1 router hop away).

The draft describes how these things might be implemented.
 
David.