RE: AD review of draft-ietf-rddp-sctp-03

"Caitlin Bestler" <[email protected]> Wed, 14 Jun 2006 16:04:13 -0700
Newsgroups gmane.ietf.rddp
Message-ID <54AD0F12E08D1541B826BE97C98F99F15766BE@NT-SJCA-0751.brcm.ad.broadcom.com>
Lars Eggert wrote:

> Section 6., paragraph 4:
> 
>  >    A DDP Stream is associated with at most one Protection Domain
>  during >    a single DDP Stream Session.
> 
>          So it can be associated with no Protection Domain?         
> When is that useful? 
> 
> 

On the passive side the association is typically deferred until 
the DDP Stream Session Accept message. If the session is rejected
then the passive side will never have an associated Protection 
Domain.

Both of those use-cases are explicitly covered in their own sections.

> Section 6.1., paragraph 2:
> 
>  >    The Payload Data Chunks for a given session, when sequenced by
>  their >    DDP-SSN, MUST follow one of the patterns defined in
> this section.
> 
>          The sequence patterns in the remainder of this section don't
>          include any DDP-SSNs? How can compliance thus be established?
> 
>

As already specified, *all* messages have a DDP-SSN:

DDP Source Stream Sequence (DDP-SSN) -
	A stream specific sequence number assigned by the Adaptation
	Layer for each SCTP Data Chunk sent. This is the order that
	chunks were submitted to SCTP, no matter what order they are
	actually sent or received in. 


> Section 6.2., paragraph 2:
> 
>  >       Active Side sends a DDP Stream Session Initiate message.
>  >       Passive Side sends a DDP Stream Session Accept message.
>  >       Each side may then send zero or more DDP Segments with
>  increasing >       DDP-SSNs, subject to various layers of flow
> control. 
> 
>          What does "various layers of flow control" mean?
>          What happens when the DDP-SSN wraps? It's no longer
> increasing then. 
> 
>

As explicitly already mentioned, the DDP-SSN wraps to zero, just
as virtually every counter in any transport protocol.
 

> 
> 
> Section 9., paragraph 2:
> 
>  >    As a Lower Layer Protocol (LLP) for DDP, the SCTP
> adaptation layer
>  >    MUST inform the DDP layer of the maximum DDP Segment size that
>  will >    be supported.  This should be the largest value that can
>  be supported >    without use of IP or SCTP fragmentation, or 516
>  bytes, whichever is >    larger.
> 
>          Why a lower bound of 516 bytes?
> 

Next paragraph.

	A minimum of 516 bytes is required to allow a DDP
	Stream Session Control Message with 512 bytes of 
	Private Data.

> 
> Section 9., paragraph 5:
> 
>  >    The SCTP adaptation layer SHOULD set the maximum DDP
> Segment size
>  >    below the theoretical maximum in order to allow bundling of
>  Control >    Chunks in the same SCTP packet.
> 
>          How much lower? How large are control chunks?
> 

See RFC2960.

There is insufficient real-world deployment data to justify
specification of any specific algorithm.