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

[Randy Stewart <[e-mail]>]

Comments in-line...

On Aug 7, 2011, at 10:50 AM, Michael Tuexen wrote:

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


There was a group when I worked at Cisco that wanted to do this, I don't
remember the reasons, but I pointed out that:

1) Each flow packet using  a  different DSCP or flow-label will appear
   in the network as having a different path (who knows how much
   different they will be .. but they will be different)

2) Since they travel different "paths" in the network, they will have
   varying RTT times.

3) They will also arrive in completely different order.

The result of this is:

a) You will get false fast retransmits
b) You MAY get unexpected HOL
c) You will generate a lot more SACK's (since holes would
   be common which normally do not do delayed sack in 
   the case of a hole).

So bottom line is its probably a bad idea.. better to setup separate associations
and just go ahead and route the traffic on the different associations for
the different priorities.

I guess if you can live with the drawbacks, it would be ok. You could
always do the sort of CMT like things that are done when CMT is on and
keep a psuedo cumulative ack on each of your separate paths.. this would
be a *LOT* of work.. but it could be done



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


Which would have the same effects for it that I list above
for SCTP.. only worse, since HOL would be set in all the
time... SCTP would escape some of it depending on what streams
were used and if unordered is thrown in the mix here too..

Also, thinking on this, how SCTP sends its FWD-TSN (what codepoint/path is
used) would become an interesting mixer to the items I listed above.

R

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

-----
Randall Stewart
[e-mail]