Subject: RE: [rddp] Let's discuss markers

From: David Borman <[email-masked]>
Date: Tue, 3 Dec 2002 15:39:28 -0600 (CST)

> Date: Tue, 3 Dec 2002 10:46:47 -0800
> From: "Somesh Gupta" <[email-masked]>
> Subject: RE: [rddp] Let's discuss markers
>
> If you look at the urgent pointer related portions of RFC 793
> (and if I recall correctly), the sender and reciever are required
> to manage only one "urgent pointer variable". This means that

Yes, but that only applies when you are dealing with in-order
processing of TCP data segments.  The only reason we are on this
topic is for processing out-of-order TCP data segments.  In that
case, we are interested in the information in the specific TCP
segment that has just been received to see if it contains a DDP
header.  So, look if the URG bit is set, and if so, if
	SEQ.SEQ + SEG.UP < SEQ.SEQ + SEG.LEN
then SEQ.SEQ + SEG.UP indicates where a DDP header is located.
You still update RCV.UP when the URG bit is set, so you can also
check to see if
	SEG.SEQ <= RCV.UP < SEG.SEQ + SEG.LEN
and if so, use that as an indication for where a DDP header is located.

> urgent pointers work as indicated by the user only when TCP can
> keep sending data - and breaks down when the window is not open
> or retransmission occurs. The window may not be open for many
> reasons including slow start, congestion avoidance or other end

Hey, if you are already modifying the receiver TCP to process
out-of-sequence TCP packets, then there is no reason why the
sender TCP can't also be modified, to allow it to maintain
urgent pointer information so that:
	ULP -- send --> TCP
	ULP -- send --> TCP
	ULP -- send --> TCP
			TCP --(send packet)-->
			TCP --(send packet)-->
			TCP --(send packet)-->

produces the same urgent pointers in the packets as:
	ULP -- send --> TCP
			TCP --(send packet)-->
	ULP -- send --> TCP
			TCP --(send packet)-->
	ULP -- send --> TCP
			TCP --(send packet)-->

> BTW, some people have indicated that PSH flag could be used for
> creating aligned segments. I believe that some 
> implementations do not follow this when window is closed or
> on retransmission.

The PSH bit is an indication from the sender TCP to the receiver TCP
that no more data is coming right now, so if the receiver TCP has been
buffering up data and not giving it to the ULP, now would be a good
time to make it available to the ULP because there isn't any more
data coming right now.  I'm not aware of any TCP implementations that
buffer up in sequence data without immediatly making it available to the
ULP; so in the TCPs I am familiar with the PSH bit doesn't do anything.

The bottom line is that if you are going to do any processing
of out-of-order TCP data, then you are changing TCP and you
shouldn't try to convince yourself that you aren't really changing
TCP because it's only getting processed by the DDP layer and isn't
being given to the ULP above DDP.  So since you are changing the
rules, you may as well make the changes to the rules as simple and
clean as you can.

		-David Borman, [email-masked]
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: "Somesh Gupta" <[email-masked]>
Date: Tue, 3 Dec 2002 14:03:18 -0800

> -----Original Message-----
> From: David Borman [mailto:[email-masked]]
> Sent: Tuesday, December 03, 2002 1:39 PM
> To: [email-masked]; [email-masked]

  You do point out the correct behavior quite well. The question
  is whether in cases where the window is closed, and
  the ULP is sending data, does the urgent pointer point so far
  into stream to make it not very useful in reducing buffering
  requirements (to the extent desired).

> ULP; so in the TCPs I am familiar with the PSH bit doesn't do anything.

  I was talking about the sender side.

> 		-David Borman, [email-masked]

While developing the iSCSI protocol, there was a firm direction
and consensus that no changes were required to TCP. The two reasons,
I think, for that decision were - so iSCSI could be layered on
top on sockets or other interfaces without change below the
sockets, and also possibly some concern that the group might run
amuck.

Somesh

---

From: Caitlin Bestler <[email-masked]>
Date: Tue, 3 Dec 2002 16:14:40 -0600

On 12/3/02, David Borman wrote:

>Yes, but that only applies when you are dealing with
>in-order processing of TCP data segments.  The only reason
>we are on this topic is for processing out-of-order TCP
>data segments.  In that case, we are interested in the
>information in the specific TCP segment that has just been
>received to see if it contains a DDP header.  So, look if
>the URG bit is set, and if so, if SEQ.SEQ + SEG.UP <
>SEQ.SEQ + SEG.LEN then SEQ.SEQ + SEG.UP indicates where a
>DDP header is located. You still update RCV.UP when the
>URG bit is set, so you can also check to see if SEG.SEQ <=
>RCV.UP < SEG.SEQ + SEG.LEN and if so, use that as an
>indication for where a DDP header is located.
>
The question is whether any TCP middleboxes might compress
multiple urgent pointers into a single urgent pointer on the
reconstituted stream.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp