RE: ISCSI: Urgent pointer consensus

["GUPTA,SOMESH (HP-Cupertino,ex1)" <somesh_gupta@hp.com>]

I have in the past raised concern about it (coalescing of
pointer). Others have raised a concern about how it may
impact TCP accelerated adapters (URG pointer presence
may kick the packet into non-fast path) - also software
interface is non-efficient.

It seems that if a connection is going at a rate where
the data transfer rate is equal or higher than the producer
rate of generating data, and there is a segment loss, then
the urgent pointer is going to help place the data in a proper
location (if the dropped PDU contained an iSCSI header
and iSCSI PDU < window size or thereabouts).

However, it is not clear to me what happens in the face of
slow start and other exception conditions.

I have some analysis below of what might happen if iSCSI
implementation and TCP implementation are not literally
mushed together.

----

First of all, slow start is likely to cause coalescing
of the Urgent pointer (at least according to my interpretation
of the 793) if the sender all of a sudden wants to send a
lot of data or the rate of production is greater than the
rate of transmission - even for short amounts of time.

Matt suggested that in case of a segment loss, the adapter
would look for the next urgent pointer and 
drop all the data between the lost segment and the next
urgent data. The result of this behavior would actually
cause the sender to make some assumptions about link
congestion (even in the presence of SACK), the results
of which are not likely to be good.

Also, what happens when a lost segment is retransmitted? Is it
supposed to carry the URG pointer, wherever it may point?

----

It seems fairly easy to create a model where iSCSI and TCP are
closely tied together and make some assumptions about the "rate
at which the application - iSCSI - is generating packets".
In this case we can use the URG pointer
to have the desired behavior - we should negotiate it i.e.
make it optional. And also very clearly specify the behavior
since RFC793 is ambigous (what happens when there is retransmission?
how to distinguish that from out of order?). The behavior may
include negotiated limits on the size of the iSCSI PDUs.

Somesh


> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Tuesday, November 14, 2000 11:17 AM
> To: ips@ece.cmu.edu
> Subject: RE: ISCSI: Urgent pointer consensus
> 
> 
> > > I also believe that based on discussion on the list, WG 
> rough consensus
> > > does NOT exist for requiring this use of the URG flag and Urgent
> pointer,
> > > (too many people have objected to making them mandatory), 
> and hence
> > > the current "MUST" will have to be replaced.
> >
> > Um, who, besides Doug, has objected?  Seems to me most of 
> the discussion
> has
> > been centered around why it would be useful.  Once the 
> reason(s) have been
> > explained, I don't see too much dissention.
> 
> That's not what I see on the list.  For starters, Daniel Smith,
> Glen Turner, and Ronald Lee have objected to the mechanism
> or specifically to making it mandatory, and I think Silvano
> Gai just added himself to that list.  More people can probably
> be found by searching the list archives.  Please don't confuse
> having the last word with winning the argument.
> 
> Thanks,
> --David
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>