Subject: Re: [Ips] iSCSI: a Reject during text negotiations

From: "Eddy Quicksall" <[email-masked]>
Date: Thu, 1 Jan 2004 17:35:55 -0500

In the example below, are you saying the first task is still active and the
initiator should send an empty text request with F=1 to allow the target to
send F=1 and the MaxRecvDataSegmentLength given by the first task should be
accepted by the target?

I.e., the reset (as indicated by Reject in section 5.4) only effects the
second task?

Eddy

----- Original Message ----- 
From: <[email-masked]>
To: "Eddy Quicksall" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, December 29, 2003 1:26 PM
Subject: Re: [Ips] iSCSI: a Reject during text negotiations

> On Wed, 24 Dec 2003, Eddy Quicksall wrote:
>
> > I think this was cleared up by Julian on Dec 22 around 1AM (no subject).
> >
> > Yes, it makes sense and I don't think I ever said anything that debated
> > that.
> >
> > My question is based on 10.10 saying:
> >
> > An initiator MUST have at most one outstanding Text Request on a
> > connection at any given time.
> >
> > I think this means only one "task" can be outstanding and I think the
"at a
> > given time" means "until the target responds with the F bit set to 1".
> >
> > So, if that is the case, the ITT can't change until the target responds
with
> > the F bit set to 1.
>
> Eddie, you are talking about an invariant of a task, the ITT, changing.
> Invariants don't change; that's the point of an invariant. :-)
>
> > My question further asked if a reject is given to an ITT that changed
before
> > F==1 (a second "outstanding Text Request") then is the original ITT
reset?
> > And the answer was [yes] because "reset is reset".
> >
> > So, in my original example given below, MaxRecvDataSegmentLength will
not
> > have changed at the target.
>
> Yes, but for a different reason. :-)
>
> It won't have changed because the first Text Negotiation task is still
> active.
>
> While I agree the second PDU should get a reject, since it's a different
> ITT, it's a different task. Since it's a different task, I don't see why
> it getting killed for a reject should impact the first.
>
> > -- snip --
> > I->T MaxRecvDataSegmentLength=512, F=0
> > T->I F=0
> > I->T (changed the ITT) F=1
> > T->I Reject
> >
> > Finally, are you saying that more than one task can be outstanding at
the
> > target before the target sets F==1? If so, we may have something to
debate.
>
> No, I'm saying that since the second PDU had a different had a different
> ITT, the target should have started up a second text nego task. Said task
> should have noticed that there already was a text nego task and thus
> aborted itself.
>
> Take care,
>
> Bill
>
> _______________________________________________
> Ips mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: [email-masked]
Date: Fri, 2 Jan 2004 10:55:36 -0800 (PST)

> I.e., the reset (as indicated by Reject in section 5.4) only effects the

Yes.

Different ITT == different task.

As I understand Reject, there is no reason it should function on more than
one ITT. So the reject shouldn't touch the first task (first ITT).

Take care,

Bill

---

From: "Eddy Quicksall" <[email-masked]>
Date: Fri, 2 Jan 2004 18:07:46 -0500

Julian,

Could I have misunderstood you? This interpretation seems to make sense.

Here is the example:

I->T, ITT=x, TTT=FFFFFFFF, MaxRecvDataSegmentLength=512, F=0
T->I, ITT=x, TTT=00000001, F=0
I->T, ITT=y, TTT=FFFFFFFF, F=1
T->I Reject (MaxRecvDataSegmentLength not changed yet)
I->T, ITT=x, TTT=00000001, F=1
T->I, ITT=x, TTT=FFFFFFFF, F=1 (MaxRecvDataSegmentLength is now 512)

Eddy

----- Original Message ----- 
From: <[email-masked]>
To: "Eddy Quicksall" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, January 02, 2004 1:55 PM
Subject: Re: [Ips] iSCSI: a Reject during text negotiations

> > In the example [above], are you saying the first task is still active
and the

---

From: [email-masked]
Date: Fri, 2 Jan 2004 18:52:31 -0800 (PST)

> T->I, ITT=x, TTT=FFFFFFFF, F=1 (MaxRecvDataSegmentLength is now 512)

I think what Julian meant was that while that analysis (above) is correct,
that other targets may have the incorrect understanding we started the
thread with. Thus that if an initiator gets such a reject, it should
realize things are quite wrong and be defensive about it. Killing the
other text task would be defensive.

Of course, there shouldn't have been a second text task. So either the
initiator is bad, or there has been some breakdown of communication
between them. For the latter, I think session reinstatement would be the
right thing to do.

Take care,

Bill

---

From: Julian Satran <[email-masked]>
Date: Sun, 4 Jan 2004 12:08:35 +0200

Eddy,

The sequence is valid.
On the other hand since the initiator missbehaves (has two outstanding 
text requests) the target may choose (and still be compliant) to 
completely reset the session etc.

Julo

"Eddy Quicksall" <[email-masked]> 
03/01/2004 01:07

To
Julian Satran/Haifa/IBM@IBMIL
cc
<[email-masked]>
Subject
Re: [Ips] iSCSI: a Reject during text negotiations

Julian,

Here is the example:

Eddy

----- Original Message ----- 
From: <[email-masked]>
To: "Eddy Quicksall" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, January 02, 2004 1:55 PM
Subject: Re: [Ips] iSCSI: a Reject during text negotiations

and the
> > initiator should send an empty text request with F=1 to allow the 
target
to
> > send F=1 and the MaxRecvDataSegmentLength given by the first task 
should
be

---

From: "Eddy Quicksall" <[email-masked]>
Date: Fri, 9 Jan 2004 13:57:37 -0500

It was determined by previous EMAIL's on this thread that a text negotiation reset (TTT=0xFFFFFFFF) only effects the ITT that is being reset.

But now I'm wondering if that was the intent of the reset. Consider the following:

I->T text request, ITT=8F, TTT=FFFFFFFF, F=0
T->I text response, ITT=8F, F=0
I->T text request, ITT=8C, TTT=FFFFFFFF (a reset)

Does the TTT=FFFFFFFF reset everything such that 8F is killed too or does it reset task 8C only?

When I first read the reset description, I thought the intent was a way for the initiator to have a clean start during a text negotiation. 

If it only resets task 8C but the initiator never finishes task 8F, what should the target do? In this case, what practical use does the reset have?

Does the task just remain outstanding until the initiator sends the F bit for task 8F?

Is this another case for Time2Retain?

Eddy

  ----- Original Message ----- 
  From: Julian Satran 
  To: Eddy Quicksall 
  Cc: [email-masked] 
  Sent: Sunday, January 04, 2004 5:08 AM
  Subject: Re: [Ips] iSCSI: a Reject during text negotiations

  Eddy, 

  The sequence is valid. 
  On the other hand since the initiator missbehaves (has two outstanding text requests) the target may choose (and still be compliant) to completely reset the session etc. 

  Julo 

        "Eddy Quicksall" <[email-masked]> 
        03/01/2004 01:07 
       To Julian Satran/Haifa/IBM@IBMIL  
              cc <[email-masked]>  
              Subject Re: [Ips] iSCSI: a Reject during text negotiations 

  Julian,

  Here is the example:

  Eddy

---

From: Julian Satran <[email-masked]>
Date: Sat, 10 Jan 2004 15:41:27 +0200

Eddy,

Evidently you sequence contains 2 pending text comands and the target 
should reject second I->T (8C) or both.

Julo

"Eddy Quicksall" <[email-masked]> 
Sent by: [email-masked]
09/01/2004 20:57

To
<[email-masked]>
cc

Subject

It was determined by previous EMAIL's on this thread that a text 
negotiation reset (TTT=0xFFFFFFFF) only effects the ITT that is being 
reset.
 
But now I'm wondering if that was the intent of the reset. Consider the 
following:

Does the TTT=FFFFFFFF reset everything such that 8F is killed too or does 
it reset task 8C only?
 
When I first read the reset description, I thought the intent was a way 
for the initiator to have a clean start during a text negotiation. 
 
If it only resets task 8C but the initiator never finishes task 8F, what 
should the target do? In this case, what practical use does the reset 
have?
 
Does the task just remain outstanding until the initiator sends the F bit 
for task 8F?

Eddy
 
----- Original Message ----- 
From: Julian Satran 
To: Eddy Quicksall 
Cc: [email-masked] 
Sent: Sunday, January 04, 2004 5:08 AM
Subject: Re: [Ips] iSCSI: a Reject during text negotiations

Eddy, 

The sequence is valid. 

Julo 

To

Julian,

Here is the example:

Eddy

---

From: Julian Satran <[email-masked]>
Date: Mon, 12 Jan 2004 17:28:55 +0200

It makes sense.
The Reject I assume is for ITT=y.

However a target might also decide to drop both x and y and reject later 
also ITT=x TTT=00001.

Regards,
Julo

To

Julian,

Here is the example:

Eddy

----- Original Message ----- 
From: <[email-masked]>
To: "Eddy Quicksall" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, January 02, 2004 1:55 PM
Subject: Re: [Ips] iSCSI: a Reject during text negotiations

and the
target
to
should
be

---

From: [email-masked]
Date: Mon, 12 Jan 2004 19:21:55 -0800 (PST)

> does it reset task 8C only?

8F is untouched. It is a separate ITT, so it is a separate task. Whatever
happens with 8C should not impact 8F.

Julian has suggested that the target may kill 8F too, since the initiator
had two outstanding text negotiations. I don't think the target should
silently do this, but I think it would be ok (not required) for the target
to kill the whole session, under the assumption that an initiator that has
two open text requests at once is on drugs. :-)

> should the target do? In this case, what practical use does the reset

Task 8F is still outstanding. The target should do whatever it does to
tasks that don't complete. It could be it just keeps the task around
forever. The initiator will log out eventually. :-)

As to what use does the reset pose? I'm not really sure. I _think_ it
would be for a case where the initiator decided it didn't want anymore
info.

I mean there are only two things you can do in a Text Negotiation. You can
announce a new MaxRecvDataSegmentLength, and you can do a SendTargets.
Only SendTargets can possibly generate so much data as to need a second
PDU, and with 8k MaxDataSegmentLength the default, it would have to be a
big list (or a really under-powered initiator) to actually do it.

So I think it'd be for a case where the initiator did a SendTargets, got
more than it expected, and decided it didn't want any more of the
negotiations.

It could also just be a bit of over-engineering. :-)

> Does the task just remain outstanding until the initiator sends the F

Yeah, it probably should.

Note that we're talking about a case where the initiator forgot what it
was doing. I don't really see this as the target's problem.

> Is this another case for Time2Retain?

I don't see why.

Take care,

Bill