[Ns-developers] Packet data replacement

[Tom Henderson]

Sorry for the late reply on this thread, which I just had a chance to 
read through.

Mathieu Lacage wrote:
> On Wed, 2009-11-18 at 14:35 +0100, Florian Schmidt wrote:
> 
> Taking a step back, I have to confess that I am not sure what you expect
> an error model which corrupts the content of a packet to really do:
> 
> 1) if you really corrupts the bits inside the packet, the ns-3 models
> are likely to stop working because most (all?) of them were written with
> the assumption that this (bit corruption) does not happen so, they will
> read corrupted headers and will fail to work, or worse.
> 
> 2) What the ErrorModel class was designed to model is the ability of a
> checksum to detect that a packet is corrupted: it just looks at the
> packet and decides whether or not your MAC-level checksum detected an
> error without having to calculate a checksum. (Maybe the doxygen for the
> ErrorModel class is misleading)

  * The main method is IsCorrupt(Ptr<Packet> p) which returns true if
  * the packet is to be corrupted according to the underlying model.
  * Depending on the error model, the packet itself may have its packet
  * data buffer errored or not, or side information may be returned to
  * the client in the form of a packet tag.
  * The object can have state (resettable by Reset()).
  * The object can also be enabled and disabled via two public member
  * functions.

  /**
   * \returns true if the Packet is to be considered as errored/corrupted
   * \param pkt Packet to apply error model to
   */
   bool IsCorrupt (Ptr<Packet> pkt);

Having written this doxygen a long time ago, I can say that I had in 
mind exactly what Florian was suggesting, that as long as we are 
carrying around packed packet data buffers, we should be able to study 
things like the effects of burst errors (possibly mutated by header 
insertion/deletion, fragmentation and reassembly, etc.) on CRC 
performance.  I also felt that the performance cost of inflating 
zero-length packets was a reasonable cost to bear for users who wanted 
to use such specialized error models.  However, none of the initial 
error models actually tries to error the byte buffer.

Because touching the raw packet data buffer is a limited use case (or 
are there others out there itching to do this kind of modeling?), I 
would probably be OK with restricting the above IsCorrupt() method to 
not allow it to touch the packet data buffer, and incurring the CopyData 
cost for those users who might want to impose error patterns on the byte 
buffer.

Tom