|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: Towards Urgent Pointer ConsensusMarjorie: In the implemenation that is most clear (netbsd) I have wondered if this is not a bug... There is only one urgent pointer (in all implementations that I have looked at). Has the urgent pointer is added to, it resets the sequence mark to this new point (+ 1, since Berkley always pointed to 1 byte past the urgent pointer mark not the last byte of the urgent pointer as the spec says). Now whenever you go to send a block of data it just does a check to see if the next segment is smaller than this urgent mark, if so it sets the URG bit and then caclulates the urgent location by a subtraction between the URG sequence number and the segement heading out... This would result in of course a bigger than 16bit value yeilding a index into the data that would be unreliable... I think the reason this is done this way is as I said, the URG pointer is designed for a small URGENT piece of information. There are comments within the code that indicate this as well. I think you will find that many implementations have taken this sort of approach.. since the point of URGENT data is "here is a small bit of info that must get there quick" NOT "I am using this to mark each frame where a header begins" This marking is a total corruption of the purpose of URGENT data and I think it is prone to many many problems if it is left in the spec... it MUST be removed IMO... R "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: > > ..snip.. > > > By "NOT work" do you mean that the framing information will > > be corrupted > > > in such a way as to cause the receiving end to fail due to > > misaligned > > > message boundary recovery? Or do you mean that it will not in all > > > cases give the performance boost it was intended to? > > > > > > > I believe it will fail due to misaligned boundary messages... > > > > > > .. more snipping .. > > > 5) The sender is still getting the highrate sent to it by > > its app. > > 6) The ONE urgent pointer starts to slide backward, ALL frames > > begin to get URGENT marks, no matter if they have a > > iSCSI header or not. > > When you refer to the urgent pointer "sliding backwards", what did you > observe? > > RFC 793 very loosely defines urgent pointer behavior, but it appears that > the coalescing allowed would still mean that a "coalesced" urgent pointer > should correctly point at some urgent data marked by the sender. (ie, it > should eventually correctly point at an iSCSI header). If an implementation > doesn't coalesce urgent pointers correctly, it seems there's bug in the > implementation. > > Even so, it seems clear to me that the TCP specification of the Urgent > pointer behavior is too loose to allow for the kind of framing that iSCSI is > looking for. Thanks for your examples, they nicely point out this ambiguity. > > Marjorie Krueger > Networked Storage Architecture > Hewlett-Packard Storage Organization > tel: +1 916 785 2656 > fax: +1 916 785 0391 > email: marjorie_krueger@hp.com -- Randall R. Stewart randall@stewart.chicago.il.us or rrs@cisco.com 815-342-5222 (cell) 815-477-2127 (work)
Home Last updated: Tue Sep 04 01:06:19 2001 6315 messages in chronological order |