Maximum frame sequence number in sliding protocols
I interpreted your question as one that is a very famous case in TCP of failing to use twice the number of sequence numbers as you would appear to need. The rule is that you may only have sequence numbers in flight (a maximum window size) that is at most half the number of sequence numbers possible given the bits you set aside for them. An example: if you have 11 bits set aside for sequence numbers in your header, you can generate 2048 different integers. You may only ever send at most 1024 bytes in a single window's worth of data. 

As you generate packets in TCP, for example, you will indicate the number of the first byte in sequence in the sequence number field. Once you reach the last number, you cycle back to 0. These are byte numbers not packet numbers. So why this rule? Because it's possible to have a receiver mis-interpret a sequence number to apply to the wrong byte in a stream.  

An example: you pick a scheme with 4 sequence numbers, 2 bits. You go about numbering bytes as you send them, 0, 1, 2, 3, 0, 1, 2, 3.  The receiver is expecting 0, 1, 2, 3 and as the arrive, it makes them available to the waiting application and sends back an acknowledgment.  But consider what happens when your four bytes are sent and arrive successfully but the acknowledgments are lost: the receiver has advanced his window expecting the second round of bytes numbered 0, 1, 2, 3, having received the prior series. The sender, however, eventually resends the original 0, 1, 2, 3 since they were never acknowledged.  It is resending its first 0, but the receiver will interpret it as the second 0 and make it available to the waiting application. Disaster. The only way to avoid this is to always have twice the number of sequence numbers than you can have bytes in-flight, sent but waiting acknowledgment.