Subject: [rddp] RE: AD review of draft-ietf-rddp-sctp-03

From: "Caitlin Bestler" <[email-masked]>
Date: Wed, 14 Jun 2006 16:04:13 -0700

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.

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

---

From: Lars Eggert <[email-masked]>
Date: Thu, 15 Jun 2006 09:39:07 +0300

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

Gotcha.

> 	actually sent or received in.

Right, but the sections following that comment don't actually  
establish any SSN sequences - they establish message sequences. (I'd  
think that an SSN pattern would look like "sender sends SSN x,  
responder sends SSN y, sender sends x+n", etc.)

> as virtually every counter in any transport protocol.

Then the wording needs to change. When the SSN wraps, the SSN  
sequence is not increasing.

(What about the flow control comment?)

> 	Stream Session Control Message with 512 bytes of

Gotcha.

> specification of any specific algorithm.

OK

Lars
-- 
Lars Eggert                                     NEC Network Laboratories