Re: Urgent as Framing Hint?

[Srinivasan Seshan <Srinivasan_Seshan@barracuda.cmcl.cs.cmu.edu>]

Maybe I don't understand some issue... but I don't see the need to move all 
this framing stuff into the TCP header. The basic desire is to be able to add 
framing to a stream based protocol. The typical solution is to use something 
like byte-stuffing - however this requires touching or having all the data and 
is therefore difficult in software at high speed....

So here is a simple alternative..... Every 4K (or possibly every time the 
sequence number is a multiple of 4K) add a 128 bytes of framing info - this 
could be contain the sequence number offset of the start of the previous or 
future several frames. This would only be a hint - i.e. it doesn't have to 
contain all such frame starts. This data will be part of the TCP payload - 
i.e. the iSCSI stream.  Or you could do something like the consistent overhead 
byte stuffing paper - just restart COBS at every 4K boundry.

Here are some simple ways to use this:
	1) Have an integrated iSCSI/TCP implementation that reads these 4K offsets 
and does the right processing and DMA
	2) Have an normal application level iSCSI and normal kernel TCP 
implementation - the iSCSI would have to read and discard the framing info
	3) You can even have a large application level buffer for the iSCSI stream 
and let TCP fill in the buffer out of order. The application could check the 
4K offsets and start processing finished blocks.

Basically, there seems to be no need to modify TCP to provide this framing. 
Just make iSCSI support fast framing on its own.

This approach is not necessarily bandwidth efficient - but everyone in this 
discussion seems to have 10Gbps links ;-) Also, the 4K and 128 bytes could be 
changed to adjust this as needed.

	Srini