Re: Apparent SCTP API oversights, draft-ietf-tsvwg-sctpsocket-30

[Michael Tuexen <[e-mail]>]

Hi Dan,

based on the discussion, I suggest the following text changes:
On Aug 5, 2011, at 2:05 AM, Dan Wing wrote:

> I would like clarification on my misunderstanding, or changes
> to draft-ietf-tsvwg-sctpsocket, to accommodate what appear to
> be some oversights in the SCTP API:
> 
> 1. The infotype parameter of sctp_sendv() allows indicating if the 
> data should be sent with partial reliability or full reliability
> using sctp_prinfo.  However, there does not appear to be a way to 
> adjust the IPv4 or IPv6 DSCP bits when switching between 
> full/partial reliablity, except by modifying the entire
> association itself (using spp_ipv4_tos).  This is quite limiting.
No changes.
> 
> 
> 2. When modifying an association (e.g., to have different DSCP
> value), I could not find text in draft-ietf-tsvwg-sctpsocket-30 that
> indicates if the modification applies immediately (including to 
> packets queued and to packets not yet acknowledged by the 
> receiver) or if the modification applies to subsequent calls
> to send().
> 
> This means that to attempt to work around (1), it isn't clear
> if the API would permit me to modify the association's DSCP
> value, call send(), and know that payload will be sent with
> the desired DSCP value.
I added at the end of section 8.1.12:
<t>Please note that changing the flowlabel or DSCP value will affect
all packets sent by the SCTP stack after setting these parameters.
The flowlabel might also be set via the sin6_flowinfo field of the
struct socketaddr_in6 structure.</t>
> 
> 
> 3. Related to (1), it is desirable that full reliable packets not
> be bundled with partial reliability packets, so that they can have
> different DSCP markings.  
> 
> http://tools.ietf.org/html/rfc4960#section-10.1 mentions a no-bundle
> flag.  However, I could not find in draft-ietf-tsvwg-sctpsocket-30 
> where this is controlled; it appears the API lacks this ability.
I added to section 8.1.5:
In particular, not using any Nagle-like algorithm might
reduce the bundling of small user messages in cases where this
would require an additional delay.</t>
> 
> 
> 4. draft-ietf-tsvwg-sctpsocket-30 uses the archaic term ToS
> rather than DSCP.  At a minimum, to ease string searching, please 
> add text near spp_ipv4_tos something like "This is also called the
> DSCP field [RFC2474]".  I would prefer, though, that 
> draft-ietf-tsvwg-sctpsocket-30 use the term DSCP in compliance 
> with RFC3260 and other DiffServ documents.
> 
> 
> 5. I believe it is an oversight that draft-ietf-tsvwg-sctpsocket-30 
> provides a way to adjust the IPv4 ToS (spp_ipv4_tos) and the IPv6
> flow label (spp_ipv6_flowlabel), but lacks a way to query or adjust
> the IPv6 Traffic Class field.  Please correct this oversight or
> add text justifying the inability to adjust the IPv6 Traffic Class
> field.
The stuff now reads:
struct sctp_paddrparams {
  sctp_assoc_t spp_assoc_id;
  struct sockaddr_storage spp_address;
  uint32_t spp_hbinterval;
  uint16_t spp_pathmaxrxt;
  uint32_t spp_pathmtu;
  uint32_t spp_flags;
  uint32_t spp_ipv6_flowlabel;
  uint8_t spp_dscp;
};

<t hangText="spp_ipv6_flowlabel:">
This field is used in conjunction with the SPP_IPV6_FLOWLABEL flag
and contains the IPv6 flowlabel. The 20 least significant bits are
used for the flowlabel.
This setting has precedence over any IPv6 layer setting.</t>
<t hangText="spp_dscp:">
This field is used in conjunction with the SPP_DSCP flag and
contains the Differentiated Services Code Point (DSCP).
The 6 least significant bits are used for the DSCP.
This setting has precedence over any IPv4 or IPv6 layer setting.</t>

...
<t hangText="SPP_IPV6_FLOWLABEL:">
Setting this flag enables the setting of the IPV6 flowlabel value.
The value is contained in the spp_ipv6_flowlabel field.
<vspace blankLines="1"/>
Upon retrieval, this flag will be set to indicate that the spp_ipv6_flowlabel
field has a valid value returned. If a specific destination address is
set (in the spp_address field), then the value returned is that
of the address. If just an association is specified (and no address), then
the association's default flowlabel is returned. If neither an association nor a
destination is specified, then the socket's default flowlabel is returned.
For non IPv6 sockets, this flag will be left cleared.</t>
<t hangText="SPP_DSCP:"> Setting this flag enables the setting of
the DSCP value associated with
either the association or a specific address.
The value is obtained in the spp_dscp field.
<vspace blankLines="1"/>
Upon retrieval, this flag will be set to indicate that the spp_dscp field
has a valid value returned. If a specific destination address is set when
called (in the spp_address field) then that specific destination address'
DSCP value is returned. If just an association is specified then
the association default DSCP is returned. If neither an association nor a
destination is specified, then the sockets default DSCP is returned.</t>

Does this address your issues?

Best regards
Michael
> 
> -d
> 
> 
>