ipid-debuggery (was Re: [e2e] ICMP & TCP segments with IP ID = 0?
dennis at juniper.net
Fri May 18 16:26:06 PDT 2001
> If you fragment packets, you can obviously increase the ID while
> fragments are created, since you are pretty much processing
> one packet..
Note that incrementing the ID when doing fragmentation is probably
not such a good idea, but I get the point. You might consider, however
that packet fragmentation is still an operation which can be computed
based solely on the contents of the current packet, without reference
to the contents of a previous packet you fragmented or knowledge of
the passage of time. If you build a processor which takes advantage
of the stateless nature of most of the operations a router does at this
point you can get pretty good mileage out of it, but you may need to
work around an occasional operation which doesn't quite work like that.
Live and learn.
> > The identification field is used to distinguish the fragments of one
> > datagram from those of another. The originating protocol module of
> > an internet datagram sets the identification field to a value that
> > must be unique for that source-destination pair and protocol for the
> > time the datagram will be active in the internet system.
Yes, this is true. I'll even avoid underlining the first sentence and
asserting that any application which is trying to use the IP ID for something
other than distinguishing the fragments of one datagram from those of
another shouldn't necessarily expect the field to be set any which-way,
though I will point out how impossibly unachievable the "time the datagram
will be active in the internet system" requirement is for a box which can
generate millions of packets per second to a single source-destination-protocol
tuple and hence wrap 16-bit values in less than the cross-continent speed
of light delay. This can't be done perfectly, so we're down to the choice
between doing it imperfectly and hoping anyone making unspecified use of the
value will forgive you, or setting it to an obvious constant so the receiver
can understand that it shouldn't trust this number. Which of these choices
is really better? I have an opinion now based on the application I've
learned about, but I do get vaguely annoyed with the notion that there
is one true answer, with any other being an evil impediment to progress,
when in reality it seems like the same sort of shades-of-gray choice that
is typical of any real-world engineering tradeoff.
> A single register is not so much expense .. is it ?
It's cheap if you understand the requirement before you start building,
but not so cheap if you only found out the requirement the day before
yesterday and it is distinctly different than all the requirements you
knew about before that. If you had to know everything the thing you are
building will be used for before you start, you'd never build anything.
The best you can do seems to be to build it as general purpose as you
can imagine before you start, and then collect the list of things that
come up that aren't quite right so you can use that to design your next
More information about the end2end-interest