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

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

> -----Original Message-----
> From: Michael Tuexen [mailto:[e-mail]]
> Sent: Sunday, August 07, 2011 7:50 AM
> To: Dan Wing
> Cc: [e-mail]; 'James M. Polk'; draft-ietf-tsvwg-
> [e-mail]; [e-mail]; [e-mail]; 'Peter
> Lei (peterlei)'; [e-mail]
> Subject: Re: Apparent SCTP API oversights, draft-ietf-tsvwg-sctpsocket-
> 30
> 
> On Aug 6, 2011, at 1:36 AM, Dan Wing wrote:
> 
> >> -----Original Message-----
> >> From: Michael Tuexen [mailto:[e-mail]]
> >> Sent: Friday, August 05, 2011 1:59 PM
> >> To: Dan Wing; [e-mail]; James M. Polk
> >> Cc: [e-mail]; [e-mail];
> >> [e-mail]; Peter Lei (peterlei);
> [e-mail]
> >> Subject: Re: Apparent SCTP API oversights, draft-ietf-tsvwg-
> sctpsocket-
> >> 30
> >>
> >> Hi Dan,
> >>
> >> thank you very much for your comments.
> >> See my answers in-line.
> >>
> >> Best regards
> >> Michael
> >>
> >> 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.
> >> A couple of points:
> >> * The DSCP stuff applies to packets, not to user messages. Any
> >>  send() call applies to a user message. So this does not really
> >>  fit.
> >> * The sendv() is a convenience function, so you can't do everything
> >>  with it. The generic way is by using CMSGs.
> >> * The DCSP stuff is related to the IP layer, not the SCTP layer.
> >> * I'm also not sure if you can easily map PR-SCTP policies to
> >>  DCSP code points. You might want to do that for particular
> >>  usages of particular policies, but in general a mapping seems
> >>  to be hard.
> >> * For IPv6 you can do that by using the IPV6_TCLASS CMSG.
> >> * For IPv4 there is no CMSG for specifying the TOS (as far
> >>  as I know). But adding such a CMSG at the IPv4 layer would
> >>  be the way to address this.
> >
> > To me this seems necessary, or else SCTP's ability to carry
> > multiple streams (of different application delivery precedence, e.g.,
> > partial reliability) cannot influence the network's drop precedence.
> If you want a per user message DSCP, that is required. However,
> we don't define any IPv[46] layer socket option or CMSG in the
> SCTP socket API ID.
> > Without this capability the only workable alternative, if someone
> > wants the  network to know the drop precedence for a packet, is
> > to create two separate SCTP associations and carry the reliable
> stream
> > in one association and the unreliable stream in the other
> association.
> > Creating a separate connection with certain DSCP values is what we
> > do with UDP and TCP today.  This limitation seems the antithesis of
> > SCTP's design which allows a single SCTP association to carry several
> > streams where each stream can have different retransmit
> > characteristics.
> Hmm. Assuming you would send user messages with a limited lifetime of,
> let's say, 5 seconds. What DSCP would you use?

The value depends on that network's configuration.  RFC4594 provides
some guidance on different values.

> For different PR-SCTP policies, this might be clearer. For example,
> FreeBSD allows to limit the number of retransmissions. For limiting
> it to 0, it might be clear, but what would be an appropriate DSCP
> with you allow, let's say, 3 retransmissions?
> 
> Or do you have a different PR-SCTP policy in mind?
> 
> In general I'm wondering how SCTP behaves if you use different
> DSCP within the same SCTP association. Not that it might break
> the association, but I'm not sure about interactions with the
> CC.
> >
> >
> >>> 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.
> >> At least for the FreeBSD implementation this applies to all
> >> packets (transmitted or retransmitted) sent after the socket option
> >> has been set. The values do NOT stick to user messages.
> >
> > This seems significant, and means an application cannot work
> > around the missing functionality in the API.  Can this be
> > added to the document?
> Up to the chairs...

?  As in, this vagueness in the API is acceptable to you?

> >>> 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.
> >> ... which means the workaround doesn't really work...
> >>>
> >>> 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.
> >> The functionality is provide by the SCTP_NODELAY socket option.
> >
> > Can the word "bundle" be added somewhere in the description of
> > SCTP_NODELAY?  Such consistency of terminology eases searching for
> > things like this.
> >
> >
> >>> 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.
> >> I'm happy to change this text. However, the document has passed
> >> the WG LC. Not sure how to handle this? WG chairs?
> >> We can either reissue he document with the small changes discussed
> >> in this mail or handle it as comments during the IESG review.
> >> Up to the chairs.
> >>
> >>> 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.
> >> Hmmm. You have a point here...
> >> It is hard to change he structure anymore since implementations are
> >> out... However, the spp_ipv6_flowlabel is 32-bit, enough space to
> >> contain the flowlabel and the DSCP. We could add text how to [sg]et
> >> the DSCP.
> >
> > That seems a reasonable solution which makes only a small change
> > to existing code.
> However, this does not solve your problem of being able to provide a
> per packet DSCP.

Agreed.  But at least it brings IPv6 on par with IPv4.

> You can do this with the IPV6_TCLASS cmsg for
> IPv6, but I'm not aware of something similar for IPv4.
> Maybe the reason is that for UDP you can do this my using a
> setsockopt()
> call before each send() call. I'm not sure if it makes sense for TCP
> to use multiple DSCPs per TCP connection.

I agree it makes little sense for TCP to change DSCP values of
a flow.  But SCTP isn't TCP, of course.

-d


> Best regards
> Michael
> >
> > -d
> >
> >> Kacheong: Do you have some suggestions here?
> >>>
> >>> -d
> >>>
> >>>
> >>>
> >
> >