Subject: [manet] MAC sequence number

From: Yougu Yuan <[email-masked]>
Date: Thu, 11 Jul 2002 13:47:06 -0400

Hi, all. Maybe it is a little bit off topic to send this question to manet, 
but I have a question about the MAC802.11 packet sequence number.

In the MAC802.11 header, there is a sequence number. In ad-hoc network, when 
two nodes meet, how do the negotiate the sequence number pair? Is there a 
special bit in the header that says "reset the sequence number of me to the 
sequence number in this packet"? I'm reading the 802.11 standard, but it's 
too thick for a quick answer.

Thanks in advance.

-- 
Yougu Yuan

----------------------------------------------------
Office Phone 603-646-0679    [email-masked]
Dept. of Computer Science, Dartmouth College

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: Yougu Yuan <[email-masked]>
Date: Thu, 11 Jul 2002 14:09:47 -0400

I think I should make my question more clear. I read some part of the 
standard. It didn't say clearly that there is anything like handshaking. 

If two nodes, A and B, just meet, they can set the sequence numbers from 
their first exchanged packets, that's ok. But if after a while, A reboots, 
coming back with a clean cache, while B still keeps the old sequence number 
cache, there is a clear mismatch that will cause them to drop packets from 
each other unless they can settle down on a new sequnce number. I'm wondering 
how this is done. Does it depends on a timer of the sequence number cache? Or 
some field in the MAC header?

On Thursday 11 July 2002 13:47, Yougu Yuan wrote:
> In the MAC802.11 header, there is a sequence number. In ad-hoc network,
> when two nodes meet, how do the negotiate the sequence number pair? Is
> there a special bit in the header that says "reset the sequence number of
> me to the sequence number in this packet"? I'm reading the 802.11 standard,
> but it's too thick for a quick answer.
>
> Thanks in advance.

-- 
Yougu Yuan

---

From: Yougu Yuan <[email-masked]>
Date: Thu, 11 Jul 2002 14:09:47 -0400

-- 
Yougu Yuan

---

From: "����" <[email-masked]>
Date: Tue, 16 Jul 2002 23:27:36 +0800 (CST)

Hi, Yougu Yuan:
    I read Glomosim source of 802.11, it uses 1 bit to represent sequence number. I think there is no need for sequence number negotiation process in the 802.11. When one of the talking side reboot, as you may discover, two sides may have different sequence number. For example, when B reboot, A's sequence number is different from B, the sequence number of A is 1, B is 0. then A send a packet with sequence number 1, B will find the packet number from A is different from what it expected from A. Then B regards this packet as an obsolete packet, return ACK with sequence number 0, and A will think that this packet is accepted by B, its sequence number will increase to 0, then two sides will have the same sequence number thereafter. I think this may be called "sequence number negotiation" if you insist, With the worst payment of 1 packet loss. However, in a real implementation, when reboot, system will become stable after a certain period(such as for route discovery), during this!
  period, a packet loss means little for the whole system. So I think if your system does not shut down and restart frequently, this simple negotiation scheme will work. No complicated sequence number negotiation process is needed.

B.R   
Hai Wang

---

From: "����" <[email-masked]>
Date: Tue, 16 Jul 2002 23:27:36 +0800 (CST)

Hi, Yougu Yuan:

B.R   
Hai Wang

---

From: "����" <[email-masked]>
Date: Wed, 17 Jul 2002 15:56:57 +0800 (CST)

Hi, Yougu Yuan:
   Firstly, I am very sorry for my misleading.:(
   I recheck the code, instead of using 1 bit, it uses "int" to represent sequence number, so it meets standard requirement. There is a bug in my mind. :)
   In fact, if 12 bit sequence number is used, same scheme which I described in last mail will work too, and packet loss probability will become ignorable.  If B restart, it may start from sequence number 0, or some random sequence number M, between 0 to 4095.  A send packet with sequence number K to B, only when [K+1]MOD 4096=M will cause packet loss. For other cases, B will discard this packet, reply ACK with sequence number M, and A will find that the sequence number of ACK is not what it expected, then A understand that the sequence number has not yet been synchronized, A change its sequence number to M, send the packet again, and B will ACK normally. Both sides will have the right sequence number from then on. 
   Surprisingly, in Glomosim source code, It is not working as I suggested. The sending packet sure has sequence number, however, the ACK does not carry any sequence number at all. I don't know how to do “sequence number negotiation” in such environment. Maybe there is someone in this mail list will give us more authoritative answer.

Hai Wang

> Thanks for checking the code. But in 802.11 standard, it uses 12 bits for the 
> sequence number, as I barely remember. So it's not a one bit change any more. 
> Of course one doesn't want to waste too many packets for the sequence number 
> mismatch. So I think in the real implementation there must be something else 
> there.
> 
> Best regards.
> 
> On Tuesday 16 July 2002 11:27, you wrote:
> > Hi, Yougu Yuan:
> >     I read Glomosim source of 802.11, it uses 1 bit to represent sequence
> > number. I think there is no need for sequence number negotiation process in
> > the 802.11. When one of the talking side reboot, as you may discover, two
> > sides may have different sequence number. For example, when B reboot, A's
> > sequence number is different from B, the sequence number of A is 1, B is 0.
> > then A send a packet with sequence number 1, B will find the packet number
> > from A is different from what it expected from A. Then B regards this
> > packet as an obsolete packet, return ACK with sequence number 0, and A will
> > think that this packet is accepted by B, its sequence number will increase
> > to 0, then two sides will have the same sequence number thereafter. I think
> > this may be called "sequence number negotiation" if you insist, With the
> > worst payment of 1 packet loss. However, in a real implementation, when
> > reboot, system will become stable after a certain period(such as for route
> > discovery), during this period, a packet loss means little for the whole
> > system. So I think if your system does not shut down and restart
> > frequently, this simple negotiation scheme will work. No complicated
> > sequence number negotiation process is needed.
> >
> > B.R
> > Hai Wang

---

From: "����" <[email-masked]>
Date: Wed, 17 Jul 2002 15:56:57 +0800 (CST)

Hi, Yougu Yuan:

Hai Wang