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

[Qiaobing Xie <[e-mail]>]

Dan,

A different way to look at this is - the overall data delivery 
reliability between two SCTP endpoints has two control points; 1) 
selectively dropping packets along the path (ie, per-hop control), and 
2) selectively retransmitting lost packets by the sending endpoint (ie, 
end-to-end control). As a transport layer protocol, SCTP naturally is 
designed to only do the latter. To ask SCTP to manage both would be 
architecturally awkward IMO.

-Q

On 8/8/11 6:27 AM, Randy Stewart wrote:
> 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]
>
>
>
>
>