|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: No FramingJohn, I understand your desire to push through an interim measure despite short-comings. With a solution available using an existing IP protocol for framing, there is no need to alter network layering to implement such a solution. Network equipment vendors will only find success supporting a reasonable number of applications. Any generic solution (hallmark of the IETF protocols) will quickly obsolete an application specific FIM leaving only difficulty for future support. Especially a generic, buffer friendly, framing solution that overcomes DoS, spoofing, router failure, head of queue blocking, while introducing increased SACK, bundling, object acknowledgement, and CRC32c error checking. Those advocating a portion of the iSCSI application be in hardware below the TCP transport should be willing to document information exchanged between layers, and the states held within this layer. You wish the IETF to endorse a scheme within a standards draft and yet not be allowed to understand its implementation. This scheme so modifies the application attempting FIM utilization, it would be impractical to describe this as not altering TCP. TCP is not just a wire specification. Changing the receive packet into a memory array needs additional clarification beyond a claim this does not change TCP. Doug > Somesh, > > This is not fair, we asked for Chip Vendors that were planning on > using it, to make themselves known and to tell us why. Without exposing > internal designs, he has tried to do that, likewise Trebia, and some > others have said they want FIMs. You may not want FIMs for your design, > but you should respect these folks that have been following our spec and > found it to be valuable in their designs. They are putting their money > on it not just talk, so we should at least give them the credit which > their position deserves. Yes, of course they are disappointed with the > rhetoric around this issue, since they and others have been following the > spec, and can not understand why others haven't, since they have > determined it to be of significant value. > > His note does speak to the issues. (And clearly has some silly parts :-) > > In fact he has found it of enough value to use now, since he believes they > can not wait for iWARP to happen before the issue is addressed (and he > really wants iWARP). It should be useful to listen to folks that are > willing to put their money where their mouth is. > > OK, that said: don't you think we can find a way to address both your > position and their position, since they both seem strong and > heart felt. I would think that the "Should Implement" or at least "May > Implement" would give both sides enough reasonable room to meet on an > even business plane. > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136, Cell: (408) 499-9702 > Internet address: hufferd@us.ibm.com
Home Last updated: Sun Feb 03 18:18:03 2002 8610 messages in chronological order |