Subject: RE: [L2tpext] Ns in ZLB ACK

From: Venkatesan Pradeep <[email-masked]>
Date: Thu, 13 Mar 2003 11:49:40 -0800

The Nr was 10. And yes, if the LAC retransmits got thru to the LNS then
then we were ok. However, if they didn't reach in time the tunnel was
brought down (after the LNS' max retransmission period expired).

Pradeep.

-----Original Message-----
From: Motonori Shindo [mailto:[email-masked]]
Sent: Thursday, March 13, 2003 1:05 AM
To: Venkatesan Pradeep
Cc: [email-masked]
Subject: Re: [L2tpext] Ns in ZLB ACK

Venkatesan,

What was the Nr of the HELLO sent by LNS? If it was 10, then LAC
sending ZLB with Ns = 40 looks violating the spec. Even if it is the
case, packet with Ns = 10 will be retransmitted by LAC and make it to
the LNS eventually, and tere will be no significant effect; it is just
one waste packet sent by LAC. If it ended up with something more
catastrophic, then implementation at either side must be broken.

Regards,

From: Venkatesan Pradeep <[email-masked]>
Subject: [L2tpext] Ns in ZLB ACK
Date: Fri, 14 Feb 2003 18:11:51 -0800

> I was testing an LNS using a Cisco LAC (IOS 12.2(T)) and observed a
> problem with the Ns in ZLB ACKs sent by the LAC. The LNS was being
> stress tested and we were seeing packet loss on it. The LNS had
> advertised a window of 20 and the next expected seq was 10. The LAC
> had sent packets with Ns = 10 thru Ns = 29 and 10 more were queued
> for transmission. The first packet (Ns = 10) didn't make it to the
> LNS. The LNS sent a HELLO packet and the LAC responded with
> a ZLB ACK with Ns = 40.
> 
> The LNS discarded the ZLB because it was outside its window. It looks
> like the LAC increments the sequence number right after queueing the
> packets for transmission and is using that for the ZLB.
> 
> I think that the LNS was right in rejecting the ZLB. Am I correct?.
> If so, what should the Ns in the ZLB be in this scenario?
>  Ns = 29: This will make sure that it is within the LNS' window but
>           given that a non-ZLB packet with Ns=29 had been transmitted,
>           the next packet (ZLB or not) should have Ns=30
>  Ns = 30: This will satisfy the Ns increment rule but the packet will
>           be outside the LNS' window.
> 
> Thanks,
> 
> Pradeep.

---

From: Motonori Shindo <[email-masked]>
Date: Tue, 18 Mar 2003 13:07:59 +0900 (JST)

Venkatesan,

Then, LAC sending ZLB ACK with Ns = 40 and the tunnel torn down are
two separate issues (I mean, what triggered the tunnel down is
unlikely to be such a ZLB ACK sent by LAC). I guess the tunnel was
torn down simply because either either side was too heavily loaded and
wasn't able to keep up.

Going back to your original question, any Ns in ZLB sent by LAC is
legitimate as long as it is within the window size advertised by the
peer, because ZLB doesn't consume sequencing number space and has no
significance per se. If Ns in ZLB has no significance, then is ZLB
subject to a window-based flow control? I think it's up to the
receiving side. Some implementation may enforce the flow control on
ZLB, and some may not. Therefore, it's safe to assume that the peer
enforces a flow control even for ZLB, and should not send ZLB with Ns
exceeding the advertised window at any time for the sake of better
interoperability. In your example, Ns = 29 is OK but Ns = 30 is not.

Regards,

From: Venkatesan Pradeep <[email-masked]>
Subject: RE: [L2tpext] Ns in ZLB ACK
Date: Thu, 13 Mar 2003 11:49:40 -0800

> >           be outside the LNS' window.
_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext

---

From: Motonori Shindo <[email-masked]>
Date: Tue, 18 Mar 2003 13:07:59 +0900 (JST)

Venkatesan,

Regards,