Subject: How to Reorder/Detect packet loss in case of Payload L2TP packets?

From: Srikrishnan <[email-masked]>
Date: Thu, 13 Apr 2000 00:52:44 -0700

Hi,

   L2TP RFC 2661 section 5.4 (give below)
"Unlike the L2TP control channel, the L2TP data channel does not use
   sequence numbers to retransmit lost data messages. Rather, data
   messages may use sequence numbers to detect lost packets and/or
   restore the original sequence of packets that may have been reordered

   during transport.  The LAC may request that sequence numbers be"

   proposes that Sequence Numbers in Payload can be used for
   reordering of data packets and/or detect packets lost.

   But how can a packet be detected if we cant resynchronize the
   Sequence number after the first packet loss.

    For ex:  If sequence 1,2,3 sent by LAC to LNS and 2 is lost. By
    what mechanism   will LNS detect the packet loss?

     Previous L2TP drafts ( earlier versions) detailed about RESET
Packet
     which can be used for resync. But RFC doesnt talk about that too.

     Can anyone please explain how this can be done.
     Am I missing something?

Regards
Srikrishnan.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 13 Apr 2000 16:08:16 -0400

>     what mechanism   will LNS detect the packet loss?

If 2 is lost, the LNS would not see it. The LNS would only see 1 and 3. 

>      which can be used for resync. But RFC doesnt talk about that too.

The Rbit was used for flow control (e.g. to allow communication of
packet loss back to the sending peer - in your example, the LAC). Flow
control was removed from the RFC.

---

From: Srikrishnan <[email-masked]>
Date: Thu, 13 Apr 2000 02:12:57 -0700

> If 2 is lost, the LNS would not see it. The LNS would only see 1 and 3.

My Point is exactly that, at the time of getting 3, how could LNS conclude
whether the packet 2 is lost or delayed in the network?
As its not serial link, there is lot of chances that the packet 2 may be
delayed.

If you see the section mentioned about, it says LNS can reorder the packet
or detect packet loss. I could'nt see any way to do that. ( may be some
timer!!)

Your response will be appreicated.

Thanks in Advance,
Srikrishnan.

---

From: Evan Caves <[email-masked]>
Date: Thu, 13 Apr 2000 16:54:47 -0700

> or detect packet loss. I could'nt see any way to do that. ( may be some

Yes you would need to use some kind of timer mechanism and possibly force
flush based on queue depth.

evan
-

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 13 Apr 2000 19:58:04 -0400

> flush based on queue depth.

Yes. But don't wait around too long as you don't want to cause the
higher layer (e.g. TCP) RTT calculations to get skewed heavily. If you
must reorder, I would recommend a very short queue with depth flush as
Evan mentioned, and perhaps a short timer as well if you can afford it
(this all depends on your scalability requirements). 

For L2 tunneled IP data packets (without stateful compression or
encryption of course), I have seen little reason in practice not to go
ahead and pass data as it is received - in order or not.