header size was Re: [ns] Trust on the simulator

[Lloyd Wood <l.wood@eim.surrey.ac.uk>]

Ah, one of my favourite bete noires...

On Fri, 30 Jun 2000, Sally Floyd wrote:

> Just as an example, the one-way TCP models, that I use myself,
> essentially assume that the header size is zero bytes, because the
> number of bytes of data consumed from the application is the same
> as the number of bytes of data that appear on the wire.  A historical
> artifact from the earlier evolution of the simulator, but not too
> good, if that fact happens to matter to your simulation, unfortunately.
> And the two-way TCP models in Agent/TCP/FullTcp, which do take into
> account header size in bytes, are not extensively validated in
> other aspects.

header size issues can get messier than that, as other parts of ns
will happily fiddle with packet sizes if it seems locally appropriate.
As it stands, this is an Extremely Bad Idea, as it promptly breaks
stuff making assumptions about packet sizes elsewhere.

Example: FullTcp wasn't working over the satellite code, since that
had copied a bit of code from elsewhere that arbitrarily increased
packet size by 20 in the routing agent - something you might do for 
the necessary tunnelling needed for separating addressing
realms, so it seemed a locally reasonable thing to do.

That killed FullTcp's rather fragile kludgy initial ACK exchange,
which checks packet size rather than just examining payload size
(which it can't, because there's no concept of header vs payload
sizes) to ensure that it's a new connection at both ends and receiving
an ACK sans body.

(then there's mip.cc, which even defines and adds its own
IP_HEADER_SIZE rather than using IP_HDR_LEN. and not even in mip.h...)

Having a linked list within the packet header for
indicating tunnelling/header overhead strikes me as very useful - you
could push (append last element) and pop (delete last element)
overhead as you encapsulate/tunnel, and if you're not left with an
empty list once you've reached the application at the other end you've
screwed up somehow and get issued with a warning.

A trivial addition, but a non-trivial change to support properly in
some existing protocols. (one-way TCP's validation suites
would change and packetSize_ would do with being renamed/adjusted,
FullTcp gets more robust handshaking, you'd start thinking about
indicating header overhead at various layers in the wireless
tracefiles...)

IMO you really do need clear header/payload separation in the packet
structure. Simulating encapsulation overheads at various layers
matters increasingly now that wireless support means that we have all
of those layers to consider - and you should be able to simulate this 
necessary overhead without immediately killing FullTcp or messing up
other simulated protocols.

L.

<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>