Subject: Re: ACKing bad packets...

From: Barney Wolff <[email-masked]>
Date: Fri, 24 Dec 1999 15:03 EST

(I'm answering not because I claim any sort of authority, just that the
authorities seem to be on vacation.)

I'd say the stop/cdn should ack the packet.  The reliable-transport
layer is below the state machine layer, and must be done first,
before looking at the type or contents of the control packet.  After
all, if the packet is determined by its Ns to be a retransmission,
it should not be processed at all, other than being ack'd.  And if
the Ns is beyond the next one expected, unless you're being fancy and
saving the packet for future use, you should just toss it.

Looked at another way, suppose a CDN did not ack the offending packet?
The sender would just send it again after a timeout.  There's no way
to "unsend" a packet or remove it from the queue of packets awaiting
acknowledgement, as long as the tunnel stays up.  By this reasoning,
a StopCCN doesn't have to ack the offending packet, because the
tunnel is coming down - but then the StopCCN would be complaining
about a packet that its Nr says it didn't get.

So, Nr says that you got it, not that you liked it.

Barney Wolff  <[email-masked]>

> From: "David Wong" <[email-masked]>
> Date: Fri, 24 Dec 1999 10:32:57 -0500
> 
> If I get back a CDN or a StopCCN for a packet because I just sent out a bad
> packet, does the CDN or StopCCN have to update Nr to ACK the bad packet that was
> just sent? Or is it in fact not supposed to have Nr of Ns+1 from the bad packet?
> 
> So, if I send out, say, a bad ICCN with Ns=3, Nr=2, that should result in the
> reception of a CDN, should the CDN have Ns=2, Nr=3 or Ns=2, Nr=4?
> 
> 
>

---

From: "W. Mark Townsley" <[email-masked]>
Date: Sun, 26 Dec 1999 01:57:39 -0500

> So, Nr says that you got it, not that you liked it.

This sentence says it all quite well.