Subject: Question about SCTP_PEER_ADDR_PARAMS socket options in Sockets API draft 11

From: Frank Filz <[email-masked]>
Date: Wed, 02 Nov 2005 14:20:31 -0800

Sridhar and I have been talking about the various options that can be
set with this socket option. I have a question about the SACK delay,
here is the description of this value from the draft:

> spp_sackdelay   - When delayed sack is enabled, this value specifies
>                   the number of milliseconds that sacks will be delayed
>                   for. This value will apply to all addresses of an
>                   association if the spp_address field is empty. Note
>                   also, that if delayed sack is enabled and this
>                   value is set to 0, no change is made to the last
>                   recorded delayed sack timer value.

Reading this, by implication, it seems that this parameter could be set
per address in the association. My question is why would one set this
per address? A SACK is usually sent on the address a data packet was
most recently received from, but may acknowledge packets received from
other addresses, further, a couple conditions require an immediate SACK
(this is the second data packet received, this is a duplicate data
packet).

Thanks

Frank Filz
IBM Linux Technology Center - Networking Team

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 09 Nov 2005 12:17:03 +0800

> (this is the second data packet received, this is a duplicate data

If an app really knows the paths to different addresses, it
may want to use different values given the path characteristics.
In fact, the two SCTP end points may coordinate to use different
addresses and expect SACK to come back at different intervals.
But I expect that for most apps, it will just set the same delay
for all peer addresses.  From an API perspective, it will be
too restrictive if we disallow setting different delay values
for different addresses.  Is there any problem of allowing this
feature?

-- 

						K. Poon.
						[email-masked]