Re: Urgent as Framing Hint?

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

David:

Great idea... even if it is a kludge. It would allow
"tightly integrated" iSCSI stacks to have a way to
accomplish their goals. Only drawback is it would
only work with specific "high performance - iSCSI
stacks". The iSCSI folks will need to figure out
if this is acceptable though... They will need to
allow for both types of operation (the kludge and non-kludge
version of TCP) in all of their devices if they want
to remain compatabile to those that do not use the kludge.
This may cause a problem, but I leave it to them to
say if it does :> 

R



"David P. Reed" wrote:
> 
> Hey, if you "integrate" TCP with iSCSI on both ends, you can use the
> following kludge to frame segments.
> 
> Use a variant TCP checksum on each datagram that starts a segment.  The
> variant checksum is created by adding in a suitable constant magic
> value.  This has a negligible effect on end-to-end error detection, and
> allows distinguishing buffer boundaries.
> 
> Since TCP's checksum is invisible to lower layers, it is "private" to the
> particular connection.
> 
> The receiver simply implements its checksum processing to accept two
> possible outcomes as "correct", and flags one of the outcomes as a segment
> hint.
> 
> I personally like this idea a lot, because any "middleboxes" that screw
> with checksums (even to check them) or translate streams will be discovered
> and shamed publicly for their egregious violation of layering.
> 
> Yes, it's a kludge, but it's one with a small, very localized effect that
> need only be supported by the iSCSI folks.
> 
> My $.02.
> At 05:47 AM 12/1/00 -0600, Randall R. Stewart wrote:
> >Matt Wakeley wrote:
> > > I am glad I put the urgent pointer proposal out there, because others have
> > > pointed out how there may be problems with using it.  I still believe that
> > > *if* TCP implementations were implemented correctly, it would work to a
> > > degree.  You however, have insisted that it was a "modification to
> > TCP", when
> > > in fact, it was never intended to be.
> > >
> >Matt:
> >
> >I am not sure what you mena by "work to a degree". I am quite sure
> >after looking at TCP and hearing feedback from David Reed, that in
> >ALL TCP implementations your idea will work a lot of the times. But
> >I am also just as sure that your idea will NOT work when faced with
> >a more than one packet loss..
> >
> >If working with only single packet losses is what you had in mind
> >then I am sure it will "work to a degree" right now. The real
> >question is do you want a solution that will break under heavy
> >load with multiple packet losses?
> >
> >I currently prefer the "magic sequence" proposal where you have
> >a special escape sequence you can look for inside the data stream.
> >I am not sure that this is managable for 10Gb data streams since
> >it will involve a lot of horse power to do it.. but so far it
> >is the only solution I can see that works reliably (if you have
> >enough CPU)...
> >
> >
> >R
> >--
> >Randall R. Stewart
> >randall@stewart.chicago.il.us or rrs@cisco.com
> >815-342-5222 (cell) 815-477-2127 (work)
> 
> - David
> --------------------------------------------
> WWW Page: http://www.reed.com/dpr.html

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