Re: iscsi : DataPDULength can differ in each direction.

[Dave Sheehy <dbs@acropora.rose.agilent.com>]

Julo,

> If they cooperate they have to share goals. The parameters you quoted 
> don't make sense per connection.
> PDUlength makes a lot of sense.

Just so I understand what you're saying you mean that

> > you 
> > either have to adopt the greatest common denominator approach (i.e. limit 
> > connections to the intersection of all individual feature sets) 

is the approach you are advocating and each operating system vendor is going
to have to develop that code if they expect to support a multi-vendor
configuration with spanning sessions?

Dave

> Julo
> 
> 
> 
> 
> Dave Sheehy <dbs@acropora.rose.agilent.com>
> Sent by: owner-ips@ece.cmu.edu
> 08-10-01 22:43
> Please respond to Dave Sheehy
> 
>  
>         To:     ips@ece.cmu.edu (IETF IP SAN Reflector)
>         cc: 
>         Subject:        Re: iscsi : DataPDULength can differ in each direction.
> 
>  
> 
> Julian,
> 
> > Implementation is not a session parameter :-)
> 
> The implementation directly affects the values that a session acquire 
> though. :-)
> 
> > What do you mean by an implementation specific parameter?  Is it that 
> > every connection has a different implementation and they cooperate?
> 
> That is the scenario I'm addressing. There has been discussion of late 
> which has indicated that initiators may have several different vendors 
> products (i.e. implementations) installed at once and that it is expected 
> that a session may span those multiple implementations. Each of those 
> implementations will have its own constraints and limitations. So, you 
> either have to adopt the greatest common denominator approach (i.e. limit 
> connections to the intersection of all individual feature sets) or you 
> allow 
> each connection to conform to the implementation that it resides on.
> 
> Dave
> 
> 
> 
> 
> --=_alternative 007343E2C2256ADF_=
> Content-Type: text/html; charset="us-ascii"
> 
> 
> <br><font size=2 face="sans-serif">If they cooperate they have to share goals. The parameters you quoted don't make sense per connection.</font>
> <br><font size=2 face="sans-serif">PDUlength makes a lot of sense.</font>
> <br>
> <br><font size=2 face="sans-serif">Julo</font>
> <br>
> <br>
> <br>
> <table width=100%>
> <tr valign=top>
> <td>
> <td><font size=1 face="sans-serif"><b>Dave Sheehy &lt;dbs@acropora.rose.agilent.com&gt;</b></font>
> <br><font size=1 face="sans-serif">Sent by: owner-ips@ece.cmu.edu</font>
> <p><font size=1 face="sans-serif">08-10-01 22:43</font>
> <br><font size=1 face="sans-serif">Please respond to Dave Sheehy</font>
> <br>
> <td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
> <br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;ips@ece.cmu.edu (IETF IP SAN Reflector)</font>
> <br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</font>
> <br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: iscsi : DataPDULength can differ in each direction.</font>
> <br>
> <br><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp;</font></table>
> <br>
> <br><font size=2 face="Courier New">Julian,<br>
> <br>
> &gt; Implementation is not a session parameter :-)<br>
> <br>
> The implementation directly affects the values that a session acquire <br>
> though. :-)<br>
> <br>
> &gt; What do you mean by an implementation specific parameter? &nbsp;Is it that <br>
> &gt; every connection has a different implementation and they cooperate?<br>
> <br>
> That is the scenario I'm addressing. There has been discussion of late <br>
> which has indicated that initiators may have several different vendors <br>
> products (i.e. implementations) installed at once and that it is expected <br>
> that a session may span those multiple implementations. Each of those <br>
> implementations will have its own constraints and limitations. So, you <br>
> either have to adopt the greatest common denominator approach (i.e. limit <br>
> connections to the intersection of all individual feature sets) or you allow <br>
> each connection to conform to the implementation that it resides on.<br>
> <br>
> Dave<br>
> <br>
> </font>
> <br>
> <br>
> --=_alternative 007343E2C2256ADF_=--