Subject: RE: [rddp] Another DDP segment question

From: "Larsen, Roy K" <[email-masked]>
Date: Fri, 18 Oct 2002 14:41:07 -0700

Hi Hemal,

Although they seem perfectly reasonable to me, I can't find anything in the
DDP draft that supports your assertions.  However, your last comment
suggests such text will be added to the draft which has always been my only
concern.

Thanks,
Roy

-----Original Message-----
From: Shah, Hemal 
Sent: Friday, October 18, 2002 2:28 PM
To: Larsen, Roy K; [email-masked]
Subject: RE: [rddp] Another DDP segment question

Roy,

See my answers below embedded within <hvs>.

Hemal

-----Original Message-----
From: Larsen, Roy K [mailto:[email-masked]] 
Sent: Friday, October 18, 2002 3:03 PM
To: [email-masked]
Subject: [rddp] Another DDP segment question

There seems to be consensus that a Data Source is free to send segments of
an ULP message in any order and overlap provided the segment with the L bit
set is sent last.  However, I need a further clarification.  Does this
reordering at the Data Source apply across ULP messages.  For example, for
untagged messages, is a Data Source free to send segments from MSN n+1
before segments from MSN n provided that the n segment with the L bit set is
sent before the n+1 segment with the L bit set?
<hvs>All the DDP Segments of an Untagged Message with MSN n are sent before
any of the DDP Segments of an Untagged Message with MSN n+1. In other words,
in the TCP stream in the sequence space, all the DDP Segments of MSN n will
appear before any of the DDP Segments of MSN n+1.<hvs> 

Section 7.3 states that Data Source MUST transmit DDP Messages in the order
they were submitted to the DDP layer.  Is the "order" dictated by when the
segment with the L bit is sent (since that is the prerequisite event for
indicating message reception to the ULP) or the first segment of an ULP
message?
<hvs> This is probably answered by the first comment. Let me try it again
with an example to aid the previous comment. If the ULP has submitted two
messages Msg 1 and Msg 2 (in that order) to DDP, then, all DDP segments of
Msg 1 will be sent before any of the DDP Segments of Msg 2. Out of all the
DDP Segments of a DDP Message, DDP will send the DDP Segment with L bit set
to 1 last. <hvs>

Certainly a segment from MSN n+1 can arrive at the Data Sink before a
segment from n, but is it valid for the n+1 segment to have a larger TCP
sequence number than n?
<hvs>Yes. In TCP arithmetic, a TCP segment containing a DDP Segment of an
Untagged DDP Message with MSN n+1 will carry larger sequence number than the
sequence number carried by a TCP segment containing a DDP Segment of an
Untagged DDP Message with MSN n.
<hvs>

Although there seems to be a reluctance to do so, I strongly urge that all
message segmentation ordering rules be explicitly stated in the draft.
<hvs> There will be more clarification in the next draft.<hvs>

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

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 18 Oct 2002 17:08:06 -0500

On 10/18/02, Larsen, Roy K wrote:

>Hi Hemal,
>
>Although they seem perfectly reasonable to me, I can't
>find anything in the DDP draft that supports your
>assertions.  However, your last comment suggests such text
>will be added to the draft which has always been my only
>concern.
>

It is the combination of section 7.3's requirement that
DDP "MUST transmit DDP Messages in the order they were
submitted to the DDP layer" and section 5's requirement
that LLP delivery (as opposed to placement) must preserve
the ordering that messages were submitted by the DDP layer.

DDP segments are part of the same message, and hence were
submitted to the DDP layer at the same time.  Therefore the
only constraint is that the untagged segment with the 'L'
bit must be the last submitted to the LLP.

Even if  a local interface COULD accept multiple tagged
writes at the same time, and therefore the sending DDP layer
was allowed  to interleave them, it would not interfere with
the Data Sink's ability to process tagged writes.

Untagged messages, by contrast, are inherently ordered. So
if a local interface allowed multiple untagged messages to
be submitted "at one time" it would have to accept them in
a ULP specified "order". Hence interleaving of untaggeed
messages on transmit would not be allowed.

That leaves the loophole, that probably should be closed,
that a local interface that accepted one or more untagged
writes and an untagged message "at the same time" MUST
consider the untagged message to have been provided later.

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

---

From: "Talpey, Thomas" <[email-masked]>
Date: Mon, 21 Oct 2002 07:52:20 -0400

>consider the untagged message to have been provided later.

I think you mean "tagged writes", but the rule you pointed
out earlier:

 >submitted to the DDP layer"

protects against this happening, doesn't it? The DDP layer has
a single-threaded issuing policy, and also a single-threaded
delivery policy - both of which stem from its use of the TCP
sequence number for ordering.

Tom.

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 21 Oct 2002 11:40:20 -0500

> >submitted to the DDP layer"

No, because each segment of a tagged DDP put is complete
by itself, there is no harm in "interleaving" multiple
"concurrent" tagged messages. Each tagged segment is
a complete tagged put in itself.

>
>protects against this happening, doesn't it? The DDP layer
>has a single-threaded issuing policy, and also a
>single-threaded delivery policy - both of which stem from
>its use of the TCP sequence number for ordering.
>

The DDP layer MUST be single threaded when dealing with the
LLP layer, and it would certainly make sense for it to be
single-threaded when it dealt with its consumers. But in a
very legalistic sense this is not currently specified,
probably because it is so obvious that this is the only way
anyone would want to work.

This is mostly a matter of fine tuning language for the sake
of completeness. I doubt anyone would actually attempt
anything to the contrary even without additional language.

Caitlin Bestler

---

From: "Talpey, Thomas" <[email-masked]>
Date: Mon, 21 Oct 2002 12:56:28 -0400

If the language permits the interleaving you state, then I agree
it should be tightened up. I'm still not completely convinced
because of the use of "DDP Message" in the ordering statement,
which is the complete, unsegmented, operation. But clarity is
good.

Tom.

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 21 Oct 2002 13:06:29 -0500

On 10/21/02, Talpey, Thomas wrote:

>If the language permits the interleaving you state, then I
>agree it should be tightened up. I'm still not completely
>convinced because of the use of "DDP Message" in the
>ordering statement, which is the complete, unsegmented,
>operation. But clarity is good.
>
>Tom.
>

Section 7.2 has very little about ordering, other than the
following:

>   At the Data Source, DDP: 
>
>     * MUST transmit DDP Messages in the order they were 
>       submitted to the DDP layer.
>

What was probably *assumed* was that the local interface
would only accept one DDP Message at a time. But this is not
stated. It is not necessarily even valid. A typical ULP
exchange would consist of zero or more tagged DDP messages
and a single untagged DDP message. There is no inherent ULP
need to order the tagged messages.

The true requirement for the local interface, which can
certainly be postponed until a draft specifically on that
topic, is that the ULP be able to submit zero or more tagged
messages followed by an untagged message in one or more
local operations, and then be able to repeat this process
to the extent of their untagged message credits.

What cannot be allowed is any local interface which confuses
the order of untagged messages or is ambiguous about which
untagged message will signal completion for which tagged
messages.

Caitlin Bestler