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

From: "Vipin Jain" <[email-masked]>
Date: Thu, 23 Aug 2001 16:19:46 -0700

Greg,

thanks for your comments.. some quick comments inline.

> > > I think the starting retry timer recommendation is 1 second.
> > > You can back it off.
> >You mean decrease it? Backing it off will worsen the situation.
> 
> I just meant to point out the timer is not fixed.  I used to 
> let it go much
> lower than 1 second because I often found LAC/LNS to be on a LAN.
agree; timer not being fixed, like what TCP does, is one way out.

> >Anyways, decreasing the timeout, IMO, might be more stress 
> (processing 
> >wise) on the implementation without any significant 
> benefit.. because the 
> >fact still remains: sender will have to retransmit each and 
> every packet, 
> >upon expiry of a timer.
> 
> Well, whatever packets are in the front half of the window.  
> Next timeout, it's
> a quarter of the window.
again agree; like what TCP does.. as mentioned in Annex A rfc2661

> >  Besides, there is a limit to which you can decrease this 
> timer because 
> > otherwise you run into a situation where you would end up sending 
> > duplicates too early.
> 
> I used the adaptive algorithm from TCP-land.
Well, TCP also queues receive window packets that are out of order..

> I know.  But I think both implementations are valid.  If you want 
> interstellar probe
> level of reliability, you preallocate all resources up to the 
> theoretical max.
> Now lots of L2TP boxes can't afford to do that, especially 
> with all the tunnels
> some customers seem to want.  So I'd hate to leave open a 
> corner case where
> you run out of queued control message buffers.
That's precisely is my point as well: "corner cases" is what the packets are
meant to be dropped. Not always. Despite, if a node wishes to drop every out
of order packets, then it better advertise its rx window size as "1" not
anything greater. This would be give an optimal network performance. Most
efficient implementation of adaptive transmit windowing can't catch up with
a peer dropping out of order in-window packets creating an artificial
congestion.

> >[2]
> >On closing a window to solve the problem: What if peer's 
> window size is 
> >3000? So you are saying retransmit all of them in one (or a couple) 
> >re-transmits to try to close the window? And by luck if any 
> one of them 
> >gets dropped by the network peer will drop the rest of them 
> anyways. And 
> >retransmit them?
> 
> See above.  Get a burst of 3000 messages within the timeout 
> period and drop the
> first one and 1500 get retransmitted (close first, then retransmit).
I see your point of view.

thanks,
-- vipin

---

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 24 Aug 2001 10:30:31 +0200

Comments on window-size and retransmission inline.

- Mark

> Vipin Jain wrote:

Not really packets, TCP windowing operates at the byte level. So, it may queue
bytes received out of order.

Anyway, TCP is known to not behave well when there is a great deal of packet
reordering. I can dig up some reports on this if you like.

> anything greater. This would be give an optimal network performance. 

I think you are focusing too much on one case, Vipin. An advertised window of 1
essentially puts the control channel into a "stop and wait" mode. Thus, each
message sent must be delayed by the 2*RTT time between the LAC and LNS + ack
processing time at the peer since the last message was sent. Only in a drastic
state of misordered packets or packet loss, or an implementation so limited in
ability that it can only operate on packets in real time without any queuing
ability whatsoever would this ever be optimal. For the former, the algorithms in
L2TP should dynamically adjust to this situation anyway. e.g. if a great deal of
packet loss is seen, one should reduce the transmit window exponentially, all
the way down to 1 if need be (unlike TCP, we cannot fall to less than a 1 packet
windowsize). The latter is a statement about the peers ability to queue and
process packets (and, to some much smaller degree, the number of packets allowed
to be in transit or queued within the intervening network).

So, again, the current and advertised initial RX buffer in L2TP is a statement
about the number of packets that are allowed to be in transit between the FSMs
on two tunnel peers at a given moment. 
Those packets may be queued within the sending box (if its output interface is
throttled), queued somewhere on the network, in transit, or sitting in an
interface or process level queue at the receiving node. If there are truly no
queues whatsoever between the LAC and LNS, and your peer can only operate on one
message at a time, then an RX window of 1 makes sense. However, this is a fairly
pitiful (and hopefully unrealistic) state of implementation.

If you look at the algorithm carefully, one can surmise that an L2TP
implementation should advertise the RX window that is based on a perfect
situation. e.g. no packet loss, low load on the box, etc. (perhaps the AVP
should be renamed to "Maximum" RX Windowsize). If packets get dropped, the
sender should reduce the window size and retransmission rate accordingly. This
packet loss may be due to load at the receiving end, or simply congestion on the
intervening network. Like TCP, the method for increasing and decreasing the
window size and retransmission rates follow a slow start and congestion
avoidance mode... e.g. decreasing exponentially and increasing linerally or
exponentially depending on the mode.

> Most
> efficient implementation of adaptive transmit windowing can't catch up with a
> peer dropping out of order in-window packets creating an artificial
> congestion.

Agreed. However, ultimately one must be just as resiliant in a high packet loss
situation as in a highly misordered situation. Even if you implement a
reordering scheme locally, you get into problems where, while waiting on an "out
of order" packet, your peer triggers an unecessary window of retransmissions if
the timing is not just right. This is one of the problems with TCP. Thus,
chronic packet misordering, in general, is something that is not tolerated well
on the internet. If you are seeing problems between an LAC and LNS, I suspect
that your TCP performance is probably suffering as well (though it may not be as
obvious to you as it is to your end-users!).