Re: checking immediate data

[Caitlin Bestler <cait@asomi.com>]

On Friday, August 8, 2003, at 10:28 AM, Eddy Quicksall wrote:

> John,
>
>  
>
> I also agree that this particular case is not a performance issue.
>
>  
>
> I tried to indicate below that the premise of making this type of 
> requirement can be extended to many other cases and if the premise is 
> acceptable, where do you stop? (E.g., one person's flag may require a 
> memory access but another person's flag may not - don't forget also 
> that the performance path may be running in on chip memory that is 
> small, so extra code to support unnecessary requirements is not a good 
> idea)? IMHO, a spec should not make these kinds of statements in a 
> performance path.
>
>  
>
> Eddy
>
I fully agree.

Keep in mind that it is very easy to make presumptions that
something is "trivial" based upon one architecture, but which
may be very difficult to do in another.

Any enumeration of specific handling for specify types of invalid
packets can force an increase in the number of rules for a state
and/or rule-based implementation. With at least some of these
engines a rule is a rule. It consumes the same amount of limited
resources no matter how "trivial" it might seem.

Personally I prefer to do packet classification independent of
stateful data (it allows more pipelining), which would make this
particular error very easy to diagnose. But not all implementations
will be optimized for high speed and pipelined execution. If an
initiator is part of an embedded device (say a piece of consumer
electronics trying to save data to an iSCSI target) then the
implementation may be very lean and mean.

If I were building such a device, I would not want to increase
my rules capacity just to facilitate debugging. I'd probably
do debugging on a enhanced version with the full rule set,
and then trim down to the minimum rule set for production
after validating that the excess rules were never triggered
during extensive debugging runs.

The general rules I have always applied to the handling of
Invalid Packets are:

-- The recipient MAY reject the packet as invalid and/or
	terminate the session.
-- The recipient MUST NOT allow the sender to gain access
	to any resource or information that the sender could
	not have accessed using legitimate packets.
--	Handling of the invalid packet MUST NOT adversely
	effect any other sessions. That is, you MUST NOT
	let an invalid packet crash the program if the
	program is dealing with other clients. Ditto for
	going into tight loops and burning up CPU time,
	responding with 10,000 acks that flood the network,
	or anything else like that.

For a specific invalid packet to be called out I think
there needs to be a benefit in terms of robustness.
That is, getting this packet represents a well recognized
state of confusion on the peers part, for which the
robust corrective action is as follows...

Failure to follow negotiated rules does not strike me
as something that deserves special robustness handling.
Not following the spec is not following the spec. The
peer has no basis to expect a "helpful" response.
Mandating that all implementations, including those
in embedded consumer devices, provide debugging
assistance to their peers would be a mistake.