[e2e] ICMP & TCP segments with IP ID = 0?

[Vernon Schryver]

> From: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>

> ...
> the net at once intentionally (note that 2^16 near MTUs worth of
> packets is quite a lot actually - its not a tcp window byte size value
> right:-)

My calculator says 2^16 times 1452 is only 95,158,272 Bytes.
That's a little high for a TCP window, but only barely worthy of comment.
There are systems doing Gbit/sec through single TCP/IP connections,
and they tend to use MByte windows.
At a mere 100 Mbit/sec on FDDI rings, it's handy to use 0.5-1.0 MByte of
window to minimize time wasted waiting for the token to go around.


> but yes, i can think of lots of optimisation/implementation reasons why
> zeroing out a packet template once per transport+ip session  
> is faster than yet another ++ operation per packet
> ...

I bet that every system where people are not doing yet another ++
operation per packet for the IP ID are wasting 1000's of cycles on
less useful things such as unnecessary locking.

The cost of the increment is at most a global memory fetch and store. 
If you keep the counter in a 1st level cache line that you need to
fondle for other reasons, such as the TSP or the route, you could
probably make the cost no more than a 3rd level cache miss.



] From: Andi Kleen <ak at muc.de>

] > but yes, i can think of lots of optimisation/implementation reasons why
] > zeroing out a packet template once per transport+ip session  
] > is faster than yet another ++ operation per packet
]
] The main problem is that userbase today wants secure ipid, not giving you cues
] on how many packets have been sent in a time range, because that information
] can be exploited by some theoretical and also some practical attacks.
] Generating "secure" ipid can be very costly. 

Your user base needs to stop listening to trade rag security experts.
It's not smart to make your security depend on information that the
bad guys can get even if you don't tell them.

But to pander to their preference for letting people who know less than
they do do their thinking, don't use a counter, but some kind of more or
less random bit generator such as the system clock.  Yes, in many (but
definintely not all) CPU's it would take too many cycles to get a
certified timestamp, so don't do that.  Look for something that changes
frequently and is not correlated


] In addition the classic global ipid counter is a contended global resource 
] on a multiprocessor stack, and maintaining it per destination also has its
] problems.

So don't use a global counter!  
For example, if you have cache-coherent memory and worry about NUMA
delays (e.g. on those systems that are moving Gbit/sec through
single TCP/IP connections), use a counter that is near the rest of
the nearby TCP, IP, UDP, or socket or other state and so doesn't
need a packet exchange.  (memory system packet, not network)
Yes, the result will be a non-unique ID, but if you have reasons to
care about speed, you've long since given up on unique ID's because
they are so obviously impossible at speed.

If you don't have coherent memory, then don't worry about it.
Let more than one IP packet go out with the same ID if they both
get sent at the same time.


Vernon Schryver    vjs at rhyolite.com