Subject: RE: TCP Framing

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Thu, 17 May 2001 16:52:59 -0400

> As I expressed in my earlier posting, the goal and purpose of 
> framing is to:
> 
> 1- eliminate the huge amounts of buffering (high speed, expensive, eats up
> board space, more expensive than fibre channel) that will be required by
10Gig
> implementations, and
> 2- provide a common feature set so that any (10Gig) implementation will be
> able to interoperate with any other iSCSI implementation, be it 1Gig,
10Gig,
> HW or SW implementations.
> 
> The only way to do this is to *mandate* implementation of some kind of
framing
> mechanism *IN THE iSCSI SPEC*.

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?

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)

- 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).

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.

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?

Marj

---

From: "Matt Wakeley" <[email-masked]>
Date: Sun, 20 May 2001 21:40:39 -0700

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

> 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).

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

> benefit us to support the common TCP framing solution and contribute to it's

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

> 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