Subject: Re: [rddp] RE: I-D ACTION:draft-stewart-rddp-sctp-01.txt

From: Randall Stewart <[email-masked]>
Date: Tue, 14 Jan 2003 09:08:33 -0600

Williams, Jim wrote:
> Some quick thoughts:
> 
> 
> 
>>  The DDP layer is responsible for submitting messages to the SCTP
>>  layer that conform to the PMTU.  The SCTP layer MAY assume this has
>>  been done.  The DDP layer MAY also wish to set the fragmentation
>>  point (usually termed SCTP_MAXSEG) to a low enough value to assure
>>  that PMTU changes will not cause IP fragmentation.
> 
> 
> I don't have a problem with the "MAY" here, but usually that
> won't be a good idea.  Receiver performance will usually be optimized
> by maximizing the fragment size.  Keeping all the chunk headers
> up front for locality of reference can only help, too.
> 
> IP fragmentation on dynamic PMTU reductions (infrequent) seems
> like a small price to pay.  Probing for larger PMTUs seems like
> a good application for multiple SCTP chunks.  Is there a NOP
> type chunk that could be used to pad out the PMTU to probe
> for larger size without needing to bother the DDP layer
> until the larger PMTU is actually observed (usually it won't
> be)?
> 
As a matter of fact, yes there is! And a couple of
implementations at bakeoffs have it implemented (not my
FreeBSD implementation however)... The Heartbeat chunk
is a completely implementation defined chunk.. it can
be as big or as small as the sending implementation wants
but it MUST be sent back intact!

So one could use it for PMTU discovery... interestingly
enough it also does a PMTU discovery in both directions :>

Do we want to add a hint in the document on this?

Maybe we need a section titled:

"Helpful SCTP implementation options"

or something to that effect

> 
>>  This mapping places an entire SCTP association into a specific DDP
>>  mode: DDP or DDP+RDMA.  It is presumed that the handling of incoming
>>  data chunks for DDP enabled associations is sufficiently different
>>  than for routine SCTP associations that it is undesirable to mix DDP
>>  and non-DDP streams in a single association.  An application that
>>  needs to mix DDP and non-DDP traffic must use more than a single
>>  association.
> 
> 
> This is not completely clear to me.  Does this mean that if the DDP+RDMA
> adaption indication is done for a specific association, then ALL traffic
> over that association is DDP+RDMA, or does it mean that DDP+RDMA may be
> negotiated and used by applications, with initial negotiation done in 
> non-DDP mode?  The former seems much clearer and less ambiguous, but
> not sure if that is how SCTP defines adoption indications.

I think the Former is the proposal.. basically you get a Adatpion
Indication at association setup.. and this places the ENTIRE association
in the DDP/RDMA mode.
> 
> 
> Using the 32 bit Payload Protocol Identifier to carry one bit of
> information looks less than optimal.  Also, with the current definition,
> the DDP and RDMA headers end up being unaligned.  I think some additional
> thought should go into optimizing the combined header format.
> 
I don't see how we can use more than a bit of it.. The PPI is meant
to identify to network elements and middle boxes as well as
the application what data is present in the chunk. To attempt
to "harness" the entire PPI is NOT in accordance with how IANA
will be assigning the PPI... using one or two of them, sort of
like a port number, IS more in line with what they were designed
for... The PPI is required to be assigned by IANA... I doubt
you can get a block of PPI's to represent RDDP... a few yes
a block no.

> 
> Regarding ordering, I would strongly support the preferred option
> of using unordered delivery.  The argument can (and has) been made
> that it is fully compliant with ordered transport semantics to
> do out of order placement, however there will be counter arguments.
> Some of those counter arguments actually seem to me to have 
> some merit.  Regardless, even if those arguments could be won,
> I don't see the down side of using unordered delivery.  If nothing
> else it should save a lot of time and reduce risk of rejection.
> 
Agreed :>

> I would suggest that using SCTP ordered delivery be considered
> as a mechanism for providing IN ORDER placement and
> IN ORDER delivery.  This could be an optional mode, but there
> may be applications where this is of significant value.
> 
sounds viable...

> Regarding the choice between option 5.1 and 5.2, I would 
> slightly favor 5.2 for its simplicity.  However, only if
> this can be done without any interoperability problems with
> normal SCTP implementations.
> 

There are currently socket options that are in the socketsapi document
that allow one to disable SCTP fragmentation... so yep.. it is
well within reason to do so...

> Section 7.2 looks incomplete to me.  Error shutdown and
> resetting of a stream needs to end to end coordination and
> requires a state machine on each end.  Maybe it's simpler
> than I think, but I think it should be documented more
> clearly.  Overall, I have some concern whether the
> complexity is justified by the value.
> 
> Section 7.1 table entry "DDP+RDMA" looks slightly off.
> 

This is a XML issue and I will see if I can get it
fixed in the next pass :>

>>If the local endpoint  only indicated
>>                 RDMA, then ONLY the procedures in
>>                 [RDMA-Draft] MUST be followed.
> 
> 
> Should be DDP rather than RDMA.  Formatting needs to be
> tweaked also.

I will get this one changed.. one of the items we
missed last time...

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

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

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

---

From: "Williams, Jim" <[email-masked]>
Date: Wed, 15 Jan 2003 10:33:03 -0500

Randall Stewart wrote:

> The PPI is meant

RFC 2960 says:

   The upper layer, i.e., the SCTP user, SHOULD standardize any specific
   protocol identifier with IANA if it is so desired.  The use of any
   specific payload protocol identifier is out of the scope of SCTP.

The phrase "SHOULD do X if it is so desired" seems a bit
self contradictory.  But it certainly suggests that
RDDP "if so desired" may choose NOT to register
the PPI with IANA and use it in a different manner
more along the lines I described. (I.e. use it to carry the
first 16 bits of the DDP header in addition to 16 other bits.
The first 16 bits of the DDP header actually describe 
the payload type, so this is in the spirit of the PPI.)

It sounds like you are implying a requirement that two different
ULPs should have a non-overlapping set of PPIs in use, but
I don't see this documented in RFC-2960, and it seems unnecessary
since the adaption indication can fully disambiguate this.

However, I am at a huge disadvantage arguing author's intent
with the author, so maybe you could elaborate a bit on this.

 Thanks, Jim