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

On Jun 15, 2006, at 2:04, Caitlin Bestler wrote:
> 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.

Gotcha.

>> 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.

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.)

>> 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.

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

(What about the flow control comment?)

>> 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.

Gotcha.

>> 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.

OK

Lars
-- 
Lars Eggert                                     NEC Network Laboratories

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