Re: TCP Framing

["John Hufferd" <hufferd@us.ibm.com>]

I must agree with Matt.  And in addition to what Matt said, about the 1 Gig
Software,  we must remember that many Desktops and Laptops, will be able to
operate with CAT 5 Cable at 100 Mb/s, and some will be happy with that,
others using the same CAT 5 cable will be able to operate comfortably at
300+ Mb/s (there will not be many that will be comfortable at 1000 Mb/s,
but most will be very happy with 300 MB/S).  So what you will see across a
business campus is software implementations running on Desktops and Laptops
at an assortments of speeds, from 100 Mb/s, through 300+ Mb/s.  There of
course will be Hardware HBAs in some Desktops, running on the same Networks
(at Gigabit Speeds), but you should expect to see lots of SW
implementations running at these lesser speeds.  To be really successful
and fulfill the real promise of iSCSI, we want both the HW and the SW
implementations to function well.

With the 100 Mb/s to 300+ Mb/s many of these Desktops and Laptops will be
getting better performance from the Network then from their local Hard
Disk.  They will have more then enough CPU power to support 300+ Mb/s and
not be noticed in the individual's system.

As Matt was saying these different, systems will get multiplexed together
into the target device, and it is important that the target device be able
to support both HW and Software implementations with a minimum of cost, on
the targets 10 Gigabit iSCSI Portals.  Though I like the Warp support, I
think it is unlikely that the TCP/IP stacks of all the different Desktops
and Laptops, etc. will be updated to support that,  in any acceptable time
frame.

I think we must depend on Markers to insure that everything can operate at
top speed, and at the lowest cost.

That is why I think that the Markers should be "Must Implement", but
"Optional to use".

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Internet address: hufferd@us.ibm.com


"Matt Wakeley" <matt_wakeley@agilent.com>@ece.cmu.edu on 05/20/2001
09:40:39 PM

Please respond to Matt Wakeley <matt_wakeley@agilent.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  Re: TCP Framing



"KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote:

> Isn't it actually that a 10Gig implementation couldn't interoperate *at
> 10Gig speeds* without some sort of frame-sync method - they would be
> considerably "slowed-down" (or forced to have large TCP rcv buffers).
This
> doesn't mean 'no interoperation', just no 10 Gig thruput?

Marj,

The issue is, there will be lots of 1Gig applications out there - perhaps
one
on every desktop.  All these 1Gig applications will be aggregated through
switches to 10Gig servers.

Now, suppose you are the vendor of this server.  Are you going to say in
your
product specification that your product will only interoperate with
applications running new TCP stacks with this new framing solution?  I'll
bet
not.  So, unless there is a framing solution mandated by the iSCSI spec
(under
the control of the iSCSI spec), you will have to implement the full TCP
buffering solution, and will have lost all the cost and space benefits of a
framing solution.

To address your other comments:

> The reason people are working so hard on a TCP-level framing solution is:
>
> - marker scheme is so krufty and software soln's are penalized (they
> probably wouldn't be able to drive 10Gig speeds if 'markers' are
mandated)

10Gig solutions will not be implemented in software, markers or not.  But
due
to aggregation, the 10Gig solutions will require the 1Gig solutions to
implement framing (markers).

> - there are other TCP applications that benefit from a common frame-sync
> method.  This makes these changes more likely to be incorporated into
> software stacks (OS releases).

Yeah, but they will require further work, and will probably be adopted
after
the new frame-sync method.  And I still question how you can require a
optional enhancement to TCP to make your new protocol work.

> There's already grumbling in IETF that 'that IPS team' "seems to exhibit
a
> strong tendency to avoid
> reusing existing IETF standards that reasonably fit their needs".  It
would
> benefit us to support the common TCP framing solution and contribute to
it's
> early adoption.

They are only grumbling because we didn't embrace their new transport with
open arms.

> Even if the TCP framing RFC wasn't mandated by iSCSI, a vendor could
require
> it's implementation end-to-end to guarantee 10Gig speeds?

See my comments above. Do you want to be the vendor that comes out with a
solution that is more restrictive than your competition? If the framing
solution is part of the iSCSI standard, then everyone will have to
implement
it to claim iSCSI compliancy.

-Matt