RE: DDP segment sequences for Untagged DDP message

Pat,
	I can see what you are saying. But I'm not sure the option of
doing both things is what we would want from the perspective of
interoperability. It's a bit of a corner case but having one system
deliver data and the other return an error is not what I would like to
see in terms of spec. development.

-----Original Message-----
From: [email protected] [mailto:[email protected]] 
Sent: Friday, January 23, 2004 4:16 PM
To: [email protected]; [email protected]
Subject: RE: [rddp] DDP segment sequences for Untagged DDP message

Barry,

How I understand clause 6.1: The transmitter committed an error. The
receiver is not required to be checking the incoming data stream for
that error. As a matter of fact the reason for requireing the last
segment to carry the highest MO was to allow the receiver to not
scoreboard and to determine message length solely from the segment with
the L bit set.

If we wanted to require the receiver to scoreboard, then we could remove
the requirement on highest MO.

Therefore, the receiver has two valid options for reacting to the
sequence: 
the one you proposed where it detects the error and reports it and 
the one Paul proposed where it delivers the message reporting a message
length of 100 bytes.

Regards,
Pat

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of Barry
Reinhold
Sent: Friday, January 16, 2004 1:07 PM
To: RDDP
Subject: FW: [rddp] DDP segment sequences for Untagged DDP message


Oops, forgot to post to reflector...

-----Original Message-----
From: Barry Reinhold [mailto:[email protected]] 
Sent: Friday, January 16, 2004 3:41 PM
To: 'Culley, Paul'
Subject: RE: [rddp] DDP segment sequences for Untagged DDP message

Paul,
	How do you understand clause 6.1 under the description of the L
bit, which reads...

        The DDP Segment with the L bit set to 1 MUST be posted to the 
        LLP after all other DDP Segments of the associated DDP Message 
        have been posted to the LLP. For an Untagged DDP Message, the 
        DDP Segment with the L bit set to 1 MUST carry the highest MO.

The second segment w/ L=1 arrives, but its MO is not the highest MO.
What happens (as in the case below) when this condition is not true?

>1. QN = 0, MSN = 1, MO = 100, L = 0, Payload = 100 bytes
>2. QN = 0, MSN = 1, MO = 0,   L = 1, Payload = 100 bytes
>Result: ULP sent Error type=Untagged Buffer Error, Error Code=Invalid
MO >[prc] No, the receiver will place both segments, but inform the ULP
that >only 100 bytes was delivered, ending at MO=99.  No error should be
detected >or reported, unless the receiver's buffer was not large enough
to hold the >second 100 bytes.

-----Original Message-----
From: Culley, Paul [mailto:[email protected]] 
Sent: Friday, January 16, 2004 3:28 PM
To: Barry Reinhold; RDDP
Subject: RE: [rddp] DDP segment sequences for Untagged DDP message

Below...

Paul R. Culley
HP Fellow
281-514-5543


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Barry Reinhold
Sent: Friday, January 16, 2004 1:09 PM
To: RDDP
Subject: [rddp] DDP segment sequences for Untagged DDP message



So, is there agreement, for the sequences that follow, that the
specified "result" given below is the correct (and desired?) behavior as
defined by the 01 draft.

Untagged DDP Segment Sequences:

1. QN = 0, MSN = 1, MO = 100 L = 1 Payload = 100 bytes
2. QN = 0, MSN = 1, MO = 0   L = 0 Payload = 100 bytes
Result: DDP Message (bytes 0-200) is delivered to ULP
[prc] yes

1. QN = 0, MSN = 1, MO = 100, L = 0, Payload = 100 bytes
2. QN = 0, MSN = 1, MO = 0,   L = 1, Payload = 100 bytes
Result: ULP sent Error type=Untagged Buffer Error, Error Code=Invalid MO
[prc] No, the receiver will place both segments, but inform the ULP that
only 100 bytes was delivered, ending at MO=99.  No error should be
detected or reported, unless the receiver's buffer was not large enough
to hold the second 100 bytes.

1. QN = 0, MSN = 1, MO = 0, L = 0, Payload = 100 bytes
2. QN = 0, MSN = 1, MO = 0, L = 1, Payload = 100 bytes
Result: DDP Message (bytes 0-100) is delivered to ULP
[prc] yes, but it is not certain which segment ends up in the buffer, it
won't matter unless the two payloads are different.

1. QN = 0, MSN = 1, MO = 000, L = 0, Payload = 100 bytes
2. QN = 0, MSN = 1, MO = 200, L = 1, Payload = 100 bytes
Result: DDP Message (bytes 0-300) is delivered to ULP
[prc] yes, but the middle 100 will contain unknown values (probably what
they had before the buffer went through DDP).

1. QN = 0, MSN = 1, MO = 300, L = 1, Payload = 100 bytes
Result: DDP Message (bytes 0-400) is delivered to ULP
(This is based on wording in 6.3, MO field. Note that the second
sentence simply says that the MO "that references the first octet MUST
be set to zero", not that a segment having a zero MO is required)
[prc] yes, but first 300 is unknown

1. QN = 0, MSN = 1, MO = 100, L = 0, Payload = 100 bytes
2. QN = 0, MSN = 1, MO = 000, L = 1, Payload = 0 bytes
Result: ULP sent Error type=Untagged Buffer Error, Error Code = Invalid
MO (There is ambiguity between 6.1 L bit field description ( Segment w/
L bit set must have highest MO), and 9.1 (implies that for non-zero
length segments the header fields are not validated.)
[prc] no, at least not because of a protocol error.  There is only an
error if the buffer limits as defined by the ULP is exceeded.  You
should get an indication that a zero length message was delivered.

1. QN = 0, MSN = 1, MO = 000, L = 0, Payload = 100 bytes
2. QN = 0, MSN = 1, MO = 100, L = 1, Payload = 0 bytes
Result: DDP Message (bytes 0 - 100) is delivered to ULP
[prc] yes

1. QN = 0, MSN = 1, MO = 100, L = 1, Payload = 0 bytes
Result: DDP Message (bytes 0 - 100) id delivered to ULP. 
[prc], yes, but with unknown data values.

Barry Reinhold
Lamprey Networks
[email protected]
(603) 868-8411
 



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


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