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

From: "Eddy Quicksall" <[email-masked]>
Date: Sat, 13 Dec 2003 16:18:04 -0500

From 5.4:

"the target sets the F bit to 1 on the last response." 

"A target may reset an operational parameter negotiation by answering a Text request with a Reject PDU."

"Parameters negotiated by a text exchange negotiation sequence only become effective after the negotiation sequence is completed."

There could be a few Text Requests used. The first one may be good but the 2nd one may be bad and rejected.

I->T MaxRecvDataSegmentLength=512, F=0
T->I F=0
I->T (changed the ITT) F=1
T->I Reject

The reject has the F bit always set to 1. So it could be considered that it ends the sequence and hence the 512 takes effect. But on the other hand, since it is used to reset the negotiation, that could be taken to mean that the good PDU should not take effect.

Can you please advise me as to the correct action?

Eddy

---

From: Julian Satran <[email-masked]>
Date: Mon, 15 Dec 2003 00:59:23 +0200

Reset is reset :-) Nothing new holds - everything is at it was at the 
outset.  Julo

"Eddy Quicksall" <[email-masked]> 
Sent by: [email-masked]
13/12/2003 23:18

To
<[email-masked]>
cc

Subject
[Ips] iSCSI: a Reject during text negotiations

From 5.4:

"A target may reset an operational parameter negotiation by answering a 
Text request with a Reject PDU."
 
"Parameters negotiated by a text exchange negotiation sequence only become 
effective after the negotiation sequence is completed."
 
There could be a few Text Requests used. The first one may be good but the 
2nd one may be bad and rejected.

The reject has the F bit always set to 1. So it could be considered that 
it ends the sequence and hence the 512 takes effect. But on the other 
hand, since it is used to reset the negotiation, that could be taken to 
mean that the good PDU should not take effect.

Eddy

---

From: [email-masked]
Date: Mon, 15 Dec 2003 10:44:46 -0800 (PST)

Sorry, Eddy, you were the only one who got the last reply. I'm resending
it.

On Sat, 13 Dec 2003, Eddy Quicksall wrote:

> "Parameters negotiated by a text exchange negotiation sequence only
> become effective after the negotiation sequence is completed."
>

I believe Julian is correct here, that a reject will reset the text
negotiation. The fact the 'F' bit is set doesn't matter; the PDU isn't a
text response PDU.

However I have a question for the list. In the example above, the second
Text Request has a different ITT than the first. Thus to a target that
sorts everything by ITT, they look like two different text negotiations
(which is an error). The reject obviously resets the "second" negotiation,
but does it also reset the first (as they look like different tasks)?

Take care,

Bill

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

---

From: "Eddy Quicksall" <[email-masked]>
Date: Mon, 15 Dec 2003 14:24:25 -0500

I agree with you and Julian both. This actually happened to me from a 3rd
party so I figured I would ask for the proper interpretation.

Regarding the changing ITT, the spec says the ITT can't change ("An
initiator MUST have at most one outstanding Text Request on a connection at
any given time") and that was the reason I gave the reject. So in my
opinion, the whole sequence must be discarded when I give the reject.

Eddy

---

From: [email-masked]
Date: Tue, 16 Dec 2003 13:33:17 -0800 (PST)

> opinion, the whole sequence must be discarded when I give the reject.

I don't take "An initiator MUST have at most one outstanding Text Request
on a connection at any given time" as meaning the ITT can't change. I take
it as meaning that you can't have two outstanding Text Requests. Since the
two requests have different ITTs, they are different tasks. The fact that
they are both Text Request tasks (of which there can be only one) is
secondary to their different ITTs.

So while we both argree that the second request is in error, the
difference is its impact on the first (and that's why I'm still EMailing
about it :-)  . Since they are different tasks, I don't see why the first
would be impacted by the (incorrect) second.

Take care,

Bill

---

From: Julian Satran <[email-masked]>
Date: Thu, 18 Dec 2003 10:13:19 +0200

I think taht you have one of those Solomonic cases in which rejecting any 
or both is legal (the come from the same initiator!).

Julo

[email-masked] 
Sent by: [email-masked]
16/12/2003 23:33

To
Eddy Quicksall <[email-masked]>
cc
[email-masked]
Subject
Re: [Ips] iSCSI: a Reject during text negotiations

Take care,

Bill

---

From: "Eddy Quicksall" <[email-masked]>
Date: Fri, 19 Dec 2003 15:05:50 -0500

This is simple for me to change my code because I could care less what the
ITT is but there is at least one party out there that thinks it can't change
(he has not spoken up yet).

I just need to know which way to go.

Julian, can you please comment definitively? Can the ITT change before the F
bit is set in a Text Response?

Eddy

---

From: [email-masked]
Date: Tue, 23 Dec 2003 12:38:07 -0800 (PST)

> (he has not spoken up yet).

The ITT can't change. If it changes, we're talking about a different task.

> bit is set in a Text Response?

Eddy, I think you're looking at this backwards. The ITT takes precedence
over the fact a PDU is a Text Request.

From section 3.2.2.1 Command numbering and Acknowledgement (para 2):

iSCSI considers a task to be instantiated on the target in response every
request issued by the initiator. A set of task management operations
including abort and reassign (see Section 10.5 Task Management Function
Request) may be performed on any iSCSI task. Some iSCSI tasks are SCSI
tasks, and many SCSI activities are related to a SCSI task ([SAM2]). In
all cases, the task is identified by the Initiator Task Tag for the life
of the task.

Note the "In all cases, the task is identified by the Initiator Task Tag
for the life of the task". If the ITT differs, we are looking at different
tasks.

So back to the original question, the ITT can't "change" for a Text
Request task, because if the ITT is different, we aren't talking about the
same task.

Does that make sense?

Take care,

Bill

---

From: "Eddy Quicksall" <[email-masked]>
Date: Wed, 24 Dec 2003 22:59:37 -0500

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.

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.

-- snip --

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.

Eddy

---

From: [email-masked]
Date: Mon, 29 Dec 2003 10:26:22 -0800 (PST)

> So, if that is the case, the ITT can't change until the target responds with

Eddie, you are talking about an invariant of a task, the ITT, changing.
Invariants don't change; that's the point of an invariant. :-)

> 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.

> 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