RE: TCP limitations (was Re: ISCSI: Urgent Flag requirementviolates TCP.)

["Bernard Aboba" <aboba@internaut.com>]

>>TCP option field to do the framing.

This is a bad idea since it will make it very difficult
to leverage the same silicon between iSCSI and other 
accelerated TCP/IP applications. 

>I believe this is clearly OUTSIDE the scope of the WG. We CANNOT
>change TCP.. period... if you desire to do this, you must take
>this to the end2end group (as Scott suggested)...

Makes you wonder what part of NO isn't understood here ;)

>Hmm, seems to me if you implement P-MTU discovery this problem would
>go away, but I do agree that if there is no P-MTU discovery you may
>have a problem with fragments....

In practice, it will be very difficult to attain the design
goals without P-MTU discovery.

>I cannot support even having this urgent method has an option. It is to
>unstable and WILL NOT work reliably...

I will check the Windows TCP/IP implementation, but I believe that you
are correct. 

>Another thought, listed in your memo is
>the choice of a "magic" signature. But this may present a problem
>as well (CPU wise) since now one must scan memory looking for the
>"magic" mark (when one gets out of sync) and of course one would
>need a escape sequence in case data heading for a disk or tape had
>the magic mark... 

In practice, this would be very difficult to pull of at 1 Gbps line 
rates. It's worth keeping in mind that at that line rate you don't have 
very many clocks, even with a 1 Ghz processor. You would need to
optimize the "magic signature" search in silicon to have a prayer
of meeting the clock budget.   

>I don't know of any other viable options though..

How about a length field?