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

["Dan Wing" <[e-mail]>]

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

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