Re: Clarification on intent of requirement

On Nov 17, 2003, at 9:01 AM, Barry Reinhold wrote:

> Clause 5 item 4 of draft-ietf-rddp-ddp-01 states:
>
>    4.  The LLP MUST preserve DDP Segment and Message boundaries at the
>        Data Sink.
>
> For the LLP to preserve the DDP segment boundary I would expect that 
> the
> LLP (MPA/SCTP) would, in some virtual API, provides an indication that
> the DDP segment is available (i.e. the full DDP segment is available in
> some buffer and is without error). Given an API this could be tested.
>
> I am not clear on what the LLP is supposed to do with a DDP message
> boundary. A DDP message boundary is defined by a bit in a DDP header 
> and
> the semantics associated with processing a DDP message do not seem to 
> be
> appropriate for the LLP. In what way is the LLP supposed to "preserve" 
> a
> DDP message?
>
>

The requirement that the LLP "preserve Message boundaries" is perhaps
misleading, because it is merely preserving the portion of the segment
that indicates it is a message boundary. But the LLP is preserving the
entire message, with no understanding of its internal structure, so of
course it preserve whatever portion is responsible for marking message
boundaries. If the draft authors want to clean the language up, fine,
but it certainly is not an error as written.

Preserving Segment boundaries is more important, and what I understood
the primary purpose of the clause to be. It is a re-affirmation that
the service offered by the LLP is reliable delivery of DDP Segments,
not byte streams.

Also, keep in mind that the virtual API between the LLP and DDP is
allowed to have *two* methods: one for placement and a second for
completion. At the time LLP completion is reported, the information
on where the DDP Segment boundaries were must not have been lost.
In particular the fact that TCP has acked a *portion* of a DDP Segment
has no meaning to the DDP layer. It is not LLP completed until the
entire segment has been LLP acked.

For the SCTP mapping, each DDP Segment is a single-chunk SCTP User
Message, so there are no potential conflicts.