Subject: rfc2661: drop out of order (within rx-window) packets..

From: "Vipin Jain" <[email-masked]>
Date: Wed, 22 Aug 2001 11:28:33 -0700

Some input for the folks who are working on new l2tp rfc:

Today's l2tp spec, rfc 2661 section 5.8. para 5, mentions:
" Messages arriving out of order may be queued for in-order delivery when
the missing messages are received, or they may be discarded requiring a
retransmission by the peer"

Further, same section, rfc recommends that retry time for a packet should be
1 second. If an implementation chooses to drop out of order packet as
opposed to queue them, it would take 1 second for a control packet to be
transmitted (once a control message is lost in the network).

In such situations, if we get incoming call rate of more than 1 call request
per second we will never be able to recover from that situation?

IMO, that's not scalable. Any thoughts?
Its easy to drop the packet and require retransmission but we should
probably get rid of this restriction and have peer queue them.

thanks,
-- vipin

---

From: "Paul W. Howard" <[email-masked]>
Date: Wed, 22 Aug 2001 14:36:25 -0400

Vipin,

An implementation should make every effort to avoid dropping these
packets, but we can't rule out dropping them as we may have no choice
but to drop a received out-of-order packet due to resource limitations.

Paul Howard

Vipin Jain wrote:

> " Messages arriving out of order may be queued for in-order delivery
> when the missing messages are received, or they may be discarded
> requiring a retransmission by the peer"
>
> Further, same section, rfc recommends that retry time for a packet
> should be 1 second. If an implementation chooses to drop out of order
> packet as opposed to queue them, it would take 1 second for a control
> packet to be transmitted (once a control message is lost in the
> network).
>
> In such situations, if we get incoming call rate of more than 1 call
> request per second we will never be able to recover from that
> situation?
>