RE: Concensus Call on Urgent Pointer.

["Dick Gahan" <Dick_Gahan@eur.3com.com>]

Firstly let me get some points clear:-

1/   iSCSI does not have a framing issue, it has the length built into the
header.
2/   The issue under discussion is a  memory issue under a dropped packet
scenario.
3/   That issue has a proposed solution which uses a TCP option, called the URG
bit.
4/   Some are proposing that all TCP implementations MUST support this option.
     (Matt Wakely, YP Cheng, Randy Haagens ?? these names come to mind, not
definitive list)
5/   Some suggest that not all TCP implementations MUST support but MAY support
it.
     (Myself, Clive Philbrick,Randall Stewart, Daniel Smith, Ronald Lee , Doug
Otis
      Somesh Gupta ?)
     Apologies if I?ve left anyone out or if I?ve included your name here
inadvertantly in favour)

On 5/ above I don?t think this negates the solution. But it does mean that all
solutions must be able
to work without use of the URG flag. From what I?ve seen on this topic this
solution PROTECTs
iSCSI in the market place in case of some device that does not like handling
URG flags (referring to Douglas Otis email).

If a Vendor wants to produce a cheap device without much memory then that is
still achievable, will work well with URG framing when negotiated, will work
well without URG framing on low loss lines and will work pretty good in most
LAN?s and MAN?s even with lossy environments (1 max frame lost every million).
So it?s just not clear to me how negotiation of this framing "makes iSCSI fail".
It does not.


Doing a TCP "special" for iSCSI seems the wrong way to go. Will some other
function come along
next year requiring another TCP special ?. Is it a good thing that many
"specials" might be developed
?. General purpose TCP handoff Engines might become obsolete if the IETF becomes
active defining
such specials. The more I think about this the more I want to oppose this option
completely. But I?ll not change
my mind just yet.


Now I want to look at the storage needs of long fat pipes (Gig Ethernet) and see
how bad is the memory problem.
Lets look at the bandwidth delay product (I guess there are some emails in the
archive already) for the LAN.

I assume a LAN with two Gigabit Ethernet switches, a server and client.



client----------------switch---------------------switch------------------server

Assume they are connected with copper at the max allowable distances i.e. 100M
between devices.

Speed of light is 300m/uS and I?ll assume speed of signal on wire at 0.5c i.e.
150m/uS:- 300M => 2uS delay

Assuming Max sized Ethernet frames, 1500bytes => 12uS to transmit at Gigabit
speed.
=> 12uS from Endstation to switch, 12uS from switch to switch and 12uS to other
Endstation => 36uS.
Lets assume each switch takes 6uS internally to switch the segment. => 12us in
total
Lets also assume that Each endstation takes 25uS to process the TCP segment.
This is acceptable for
Hardware based TCP Engines.(100?s of ms for software based solutions)

Thus the one way trip time is 2uS + 36uS + 12uS + 25uS => 75uS
Round trip time = 150uS
Number of packets on wire = 140uS/12uS each =>12.5 packets @ 1518bytes = 19KB

Thus in a LAN environment with two switches and 300M between client and server
and assuming
25uS of endstation processing 19KB is the bandwidth delay product.

This is for one TCP connection, but if there are multiple connections they
cannot be all active at a Gigabit each, thus each window can be reduced.

To support a 100 such connections then 100x19KB = 1.90MB
To support a 500 such connections then 500x19KB = 10MB. (i.e. $10)

If there are more than a 500 connections then each window gets scaled back
somewhat.

So in the LAN the memory requirements seem acceptable and not too costly.
Most iSCSI deployments will be into the LAN.


MAN Environment.

Assume 10KM(max FC distance?) fibre optic connection

At 0.5c  we get a distance of 1KM per 7uS and 10KM for 70uS and 140uS roundtrip.
Lets add this to the above figues giving a total of 140uS fibre + 150uS for
switches and end station delay.
Lets make this a round figure of 300us

Data in pipe = 300us/12us per packet = 25 packets = 25 * 1518Bytes = 38KB
So if acks can be sent out speedily from the end stations (assuming hardware
based TCP Engines at
both ends) then these numbers can be met.

If we allow enough memory for 10 such connections we have 380KB
If we allow enough memory for 100 such connections we have 4MB
If we allow enough memory for 200 such connections we have 8MB ($8)

(I know that the bandwidth delay product does not have to be given per
connection but to the total of
connections dataflow => line bandwidth).

Thus I do not see that there is a need for 100?s of megabytes of buffer ram in
MAN connections either.

So In summary , for LAN and MAN Environments the supposed memory requirements
without URG
framing seem inflated: So what am I missing here - since others have strongly
opposing views.
Note-Vendors can have even less memory than given above if they want to throw
away all data within a
 window when a segment gets lost, and re-transmit everything. Using multiple TCP
pipes in parallel
this may even be ok.

So I still say this must be optional (and I?m veering to suggesting that it
should be taken out completely).

Dick Gahan
3Com



PLANET PROJECT will connect millions of people worldwide through the combined
technology of 3Com and the Internet. Find out more and register now at
http://www.planetproject.com