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

From: Ignacio Goyret <[email-masked]>
Date: Wed, 22 Aug 2001 12:27:01 -0700

At 11:28 AM 8/22/01 -0700, 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? 

Yes: open one control connection per call. Your call rate
will no longer be limited by the L2TP retransmission rate.

>Its easy to drop the packet and require retransmission
>but we should probably get rid of this restriction and
>have peer queue them.

A better alternative is to use better timeout algorithms or move
the control connection to TCP, which handles retransmission much
better.

The fixed 1-second initial timeout is quite lousy in high call rate
systems, as you found out.

---

From: "Paul W. Howard" <[email-masked]>
Date: Wed, 22 Aug 2001 15:44:39 -0400

> will no longer be limited by the L2TP retransmission rate.

Hmmm...I'd suggest that this presents scalability problems of it's own
as you now double the number of packets requires to setup each session
(since you are setting up a tunnel for every session) and you are
increasing the increasing the amount of traffic from 1 hello per hello
interval to 'n' hellos per hello interval (given 'n' sessions are now
over 'n' tunnels instead of over 1 tunnel).

> the control connection to TCP, which handles retransmission much

It might be better with TCP handling the reliability, but this would
increase the load on the system as we would now have both L2TP and TCP
doing reliable transmission.  If we were to drop the reliability of the
L2TP control channel, then we wouldn't have reliability for L2TP over
other transports such as ATM.

> systems, as you found out.

Paul Howard

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 22 Aug 2001 23:49:33 +0200

> the control connection to TCP, which handles retransmission much

Ah, but TCP has its own scalabilty issues when you use it for signalling
applications.

> systems, as you found out.

Well, it is supposed to be somewhat adaptable.

If we really want to do things from scratch, we would probably end up using SCTP
or some such for the control channel. It should scale better for these types of
exchanges than TCP, thought it is not exactly ubiquitous.