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

[Alex Cannara]

Wow Vernon,

I'd no idea this was so sensitive a subject for you.  Since you're often
so sure of things, you must have steeled yourself over the years, when
found wrong, as ordinary folk have.  In this case, my having never been
closer to x.25 than a Stallings book, your guess on the origin of my
ideas on what to count in packets is simply a bad guess.  Again, a
symptom of a narrow view.  

Your hurdle of 5 examples is easily crossed, since I've personally done
network consulting work for >1500 companies in the last decade or so and
have seen more than twice your hurdle of looped situations that the IP
ID was quickly helpful in resolving.  Associates of mine can make
additions to the list.  I'll just mention a few of your "trade-rag"
misled organizations:  CIBC, Chase Manhattan, HUD, CBOT, Boeing, St.
Paul Cos., Intuit, Goldman Sachs, Pharmacia, ATT, yadda, yadda.

And "...loop resolution by hubs, switches, or bridges that Mr. Cannara
claimed" is also a contruct in your head alone, since I never claimed
that implementation in transmission components was requisite to valuing
the IP ID field -- it has value regardless of how it's used in
delooping.

Having something useful: "...merely for the entertainment of consultants
who cannot find other unique stigmata in packets displayed by one brand
of packet snooper" is always related to real cost -- if having the ID
allows detecting a loop in 2 minutes, it's worth quite a bit at
consulting rates.  What's your patented technique that someone will pay
you $250/hr for?

Finally: "...then all I can say is that I think I'll ask someone else to
define the next protocol I buy."  I'm sure this isn't all you can say
Vern; and what protocol salespeople are you being bugged by, Mr.
Schryver?   :]

Alex


Vernon Schryver wrote:
> 
> > From: Alex Cannara <cannara at attglobal.net>
> 
> > Well, Vernon, I just love these emails.  {:o]
> >
> > By the way, why is x.25 always the straw man?  Are other arguments so
> > weak?
> 
> No, my honest best guess for why Mr. Cannara has been for years so enthused
> about counting packets instead of bytes and about the IP ID's is that he
> first learned about network stuff by reading a trade rag description of
> x.25.  We all have the most affection for our first systems, protocols,
> and so forth, and to our personal detriment if they were not so obscure
> and weird that we're not tempted to promote our first love as the end-all.
> Replacing the TCP sequence number with a windowed packet ID like the IP
> ID does not produce x.25, but it is a major step.
> 
> > Here's a partial delooping list over the last several years...
> >
> > Sniffer(r) used to discover complex hub miswiring causing looped IP pkts
> > ...
> 
> > Sniffer(r) used to discover Cisco Cat5000 Spanning-Tree fault, looping
> > ...
> 
> > Sniffer(r) located bridging loop in Federal agency's network that
> > ...
> >
> > There are several more, but this is sufficient to demonstrate why the
> > narrow view:  "the IP ID is not now and never has been either sufficient
> > or necessary for anything that might be called loop resolution" is
> > indeed narrow.
> 
> On the contrary, those three (3) instances have nothing to do with
> anything that might be called loop resolution by hubs, switches, or
> bridges that Mr. Cannara claimed as the justification for the IP ID
> field.  They are also are fewer than the 5 I predicted would be the
> limit of what Mr. Cannara could list as examples of a human figuring
> out problems.  Moreover, there is no evidence that in those three cases
> there was not plenty of other uniqueness in the looping packets that
> would have been sufficient for other people to diagnose the problems.
> 
> Perhaps I misunderstood what Mr. Cannara meant when he spoke of loop
> resolution.  I assumed he meant hardware and software using something
> other than the TTL field, because he mentioned that the "TTL is only
> decremented by routers, not hubs/switches/bridges."  If instead he
> thinks that a 16-bit (or preferably larger) field should be maintained
> in all packet headers merely for the entertainment of consultants who
> cannot find other unique stigmata in packets displayed by one brand
> of packet snooper, then all I can say is that I think I'll ask someone
> else to define the next protocol I buy.
> 
> >                 I should add that problems like these are extremely
> > expensive to companies when they occur, so assuming things are ok
> > because some Linux boxes have avoided the intent, if not letter, of a
> > sensible RFC is naive and inconsiderate of the real folks in real places
> > that have to deal with products decendent from hubric network
> > 'experts'.  The above problems all had existed for a week to a month,
> > even jeopardized some large Cisco sales (we see how important that was
> > :) and cost $250/hour + travel to fix.
> 
> Many of us have dealt with many packet loop problems in customer networks
> over the decades.  Several years ago, about the time marketeers introduced
> "switch" instead of "multi-port bridge" and espically "stupid multi-port
> bridge without learning, spanning tree, or anything else you'd expect,"
> packet looping problems were more common than they are now.  Most of us
> do not find it necessary to rely on the IP ID field to figure out such
> problems.  Some of us know that the ID field has not been a reliable
> indicator for many years, and for that and other reasons look at more
> than just the IP header when figuring things out.
> 
> The main problem of network hubris is not in the IETF, but among the
> trade rag experts who, except for a few exceptions who prove the rule,
> know little that is true and a lot that is false.  That would not be
> a problem for the rest of us, except that the trade rag experts spend
> so much effort distributing their special kind of wisdom.
> 
> Vernon Schryver    vjs at rhyolite.com