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

[Michael Tuexen <[e-mail]>]

On Aug 10, 2011, at 12:35 AM, Dan Wing wrote:

> Yes, thanks.  
> 
> With the datastructure renamed from spp_ipv4_tos to spp_dscp, I assume you
> would also change prose from ToS to DSCP?
> 
> #grep -nE "tos|ToS|TOS" draft-ietf-tsvwg-sctpsocket-30.txt
> 3825:     uint8_t spp_ipv4_tos;
> 3872:   spp_ipv4_tos:  This field is used in conjunction with the
> 3873:      SPP_IPV4_TOS flag.  This setting has precedence over any IPv4
> 3924:      SPP_IPV4_TOS:  Setting this flag enables the setting of the IPV4
> 3925:         TOS value associated with either the association or a specific
> 3926:         address.  The value is obtained in the spp_ipv4_tos field.
> 3929:         spp_ipv4_tos field has a valid value returned.  If a specific
> 3931:         field) then that specific destination address' TOS value is
> 3933:         association default TOS is returned.  If neither an
> association
> 3934:         nor a destination is specified, then the sockets default TOS
> is
Yes, that is the text at the end of my e-mail...

Best regards
Michael
> 
> -d
> 
>> -----Original Message-----
>> From: Michael Tuexen [mailto:[e-mail]]
>> Sent: Tuesday, August 09, 2011 2:07 PM
>> To: Dan Wing
>> Cc: [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; 'Peter Lei
>> (peterlei)'; [e-mail]
>> Subject: Re: Apparent SCTP API oversights, draft-ietf-tsvwg-sctpsocket-
>> 30
>> 
>> 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
>>> 
>>> 
>>> 
> 
>