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

[Michael Tuexen <[e-mail]>]

On Aug 8, 2011, at 8:21 PM, Dan Wing wrote:

>> -----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.
Hmmm. I could not find enough guidance to choose the right value if
the timeout is 5 seconds compared to 1 second compared to 10 seconds.

But as I said and Randy wrote in more detail. I'm not sure if
it is wise to use multiple DSCP per path. So fixing the sctp_paddrparams
is helpful and within the scope of the document. I'll prepare a proposed
change of text. If you want per user message behavior you need
an IP level cmsg which is not within the scope of this document.
> 
>> 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?
I'll send out a proposed text change later. But the document is *after* WG LC.
So we have two choices:
1. After agreeing that the suggested text resolves your issues, resubmit
   the ID. Progress the new version to the IESG.
2. Handle your comments as comments received within the IESG review.
I have done both (with different documents) depending on what the WG chairs
prefer.
> 
>>>>> 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.
Yes.
> 
>> 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
>>>>> 
>>>>> 
>>>>> 
>>> 
>>> 
> 
>