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

From: "Vipin Jain" <[email-masked]>
Date: Wed, 22 Aug 2001 12:45:08 -0700

I agree an implementation should make every effort to avoid dropping these
packets, but there are implementations that drop each and every such packet
(out of order in-rx-window) and are happy to go away with saying they are
complying with rfc 2661
 
thanks,
-- vipin

-----Original Message-----
From: Paul W. Howard [mailto:[email-masked]]
Sent: Wednesday, August 22, 2001 11:36 AM
To: Jain, Vipin [SC9:T337:EXCH]
Cc: [email-masked]' '
Subject: Re: rfc2661: drop out of order (within rx-window) packets..

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: 

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 15:50:06 -0400

Perhaps the wording should be changed to stress the need to queue
out-of-order packets to avoid unnecessary retransmissions, but I don't
think we can change the wording to say that you must queue the packets
since you can't guarantee to have the resources to perform the queueing
action.

It would seem that lowering the recommended timeout could be worse than
the disease as it could lead to premature re-transmissions in a system
that is heavily loaded.

Paul Howard

Vipin Jain wrote:

>  I agree an implementation should make every effort to avoid dropping
> these packets, but there are implementations that drop each and every
> such packet (out of order in-rx-window) and are happy to go away with
> saying they are complying with rfc 2661thanks,-- 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?
>     >
>     > 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
>