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

["Randall R. Stewart" <randall@stewart.chicago.il.us>]

Bernard Aboba wrote:
> 
> >>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 ;)
> 

Yeah, it seems to me people keep forgetting this :-)

> >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?

Do you mean lenght as in fixed length ISCSI packets always? I believe
this was proposed... if you have a length field imbedded in the
TCP stream, you run in to the same problem with the current ISCSI
header (I think it has alength in it) in that if a SMS is lost
that happens to hold the next length, you must wait since you
have no idea where the next length is... Or did you have a different
length in mind???


R
-- 
Randall R. Stewart
randall@stewart.chicago.il.us or rrs@cisco.com
815-342-5222 (cell) 815-477-2127 (work)