* [PATCH 5/7] [DCCP]: Introduce two new socket options
@ 2006-09-22 2:30 ` Ian McDonald
0 siblings, 0 replies; 12+ messages in thread
From: Ian McDonald @ 2006-09-22 2:30 UTC (permalink / raw)
To: Arnaldo de Melo, David Miller, dccp (vger), Ian McDonald, netdev
This creates two new socket options DCCP_SOCKOPT_TX_PACKET_SIZE
and DCCP_SOCKOPT_RX_PACKET_SIZE. DCCP_SOCKOPT_PACKET_SIZE doesn't
work and packet size should be set independently on two half
connections.
Signed-off-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
---
diff --git a/include/linux/dccp.h b/include/linux/dccp.h
index a073164..ef1c57b 100644
--- a/include/linux/dccp.h
+++ b/include/linux/dccp.h
@@ -200,6 +200,8 @@ #define DCCP_SOCKOPT_PACKET_SIZE 1
#define DCCP_SOCKOPT_SERVICE 2
#define DCCP_SOCKOPT_CHANGE_L 3
#define DCCP_SOCKOPT_CHANGE_R 4
+#define DCCP_SOCKOPT_TX_PACKET_SIZE 5
+#define DCCP_SOCKOPT_RX_PACKET_SIZE 6
#define DCCP_SOCKOPT_CCID_RX_INFO 128
#define DCCP_SOCKOPT_CCID_TX_INFO 192
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH 5/7] [DCCP]: Introduce two new socket options
2006-09-22 2:30 ` Ian McDonald
@ 2006-09-22 10:37 ` Gerrit Renker
-1 siblings, 0 replies; 12+ messages in thread
From: Gerrit Renker @ 2006-09-22 10:37 UTC (permalink / raw)
To: dccp
| This creates two new socket options DCCP_SOCKOPT_TX_PACKET_SIZE
| and DCCP_SOCKOPT_RX_PACKET_SIZE. DCCP_SOCKOPT_PACKET_SIZE doesn't
| work and packet size should be set independently on two half
| connections.
I disagree with this solution: it solves one problem by introducing two
new ones:
* the options are redundant:
--at the sender the packet size is implicitly communicated via the
`len' argument of dccp_sendmsg()
--the receiver samples the packet sizes of incoming packets
* it makes the programming interface more complex; currently these options
only work for CCID 3 (cf. patch 6/7)
* both CCID 2/3 are for fixed-packet sizes anyway, and the upcoming
CCID 4 draft-ietf-dccp-tfrc-voip-05.txt looks much rather like a
fixed `mini' packet size rather than a variable-size protocols
* for varying packet sizes, the sender should calculate the mean/avg
packet size by itself, rather than relying on information. For TFRC,
[draft-floyd-rfc3448bis-00, sec. 4.1] suggests here:
"where the segment size varies depending on the data, the sender MAY estimate the
segment size s as the average segment size over the last four loss intervals."
In summary, I think it would be better to let the sender/receiver determine the
packet size from already available data. That is, derive s from the `len' of dccp_sendmsg(),
and use a weighted-average mechanism like
s = q * len + (1-q) * s
to smooth out variations: in accordance with draft-floyd-rfc3448bis-00.
-- Gerrit
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH 5/7] [DCCP]: Introduce two new socket options
@ 2006-09-22 10:37 ` Gerrit Renker
0 siblings, 0 replies; 12+ messages in thread
From: Gerrit Renker @ 2006-09-22 10:37 UTC (permalink / raw)
To: Ian McDonald; +Cc: Arnaldo de Melo, David Miller, dccp (vger), netdev
| This creates two new socket options DCCP_SOCKOPT_TX_PACKET_SIZE
| and DCCP_SOCKOPT_RX_PACKET_SIZE. DCCP_SOCKOPT_PACKET_SIZE doesn't
| work and packet size should be set independently on two half
| connections.
I disagree with this solution: it solves one problem by introducing two
new ones:
* the options are redundant:
--at the sender the packet size is implicitly communicated via the
`len' argument of dccp_sendmsg()
--the receiver samples the packet sizes of incoming packets
* it makes the programming interface more complex; currently these options
only work for CCID 3 (cf. patch 6/7)
* both CCID 2/3 are for fixed-packet sizes anyway, and the upcoming
CCID 4 draft-ietf-dccp-tfrc-voip-05.txt looks much rather like a
fixed `mini' packet size rather than a variable-size protocols
* for varying packet sizes, the sender should calculate the mean/avg
packet size by itself, rather than relying on information. For TFRC,
[draft-floyd-rfc3448bis-00, sec. 4.1] suggests here:
"where the segment size varies depending on the data, the sender MAY estimate the
segment size s as the average segment size over the last four loss intervals."
In summary, I think it would be better to let the sender/receiver determine the
packet size from already available data. That is, derive s from the `len' of dccp_sendmsg(),
and use a weighted-average mechanism like
s = q * len + (1-q) * s
to smooth out variations: in accordance with draft-floyd-rfc3448bis-00.
-- Gerrit
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 5/7] [DCCP]: Introduce two new socket options
2006-09-22 10:37 ` Gerrit Renker
@ 2006-09-22 16:56 ` Eddie Kohler
-1 siblings, 0 replies; 12+ messages in thread
From: Eddie Kohler @ 2006-09-22 16:56 UTC (permalink / raw)
To: dccp
Hi, just a couple clarifications and notes. I haven't deeply thought through
the new socket options, but disagree with your objections :)
Gerrit Renker wrote:
> | This creates two new socket options DCCP_SOCKOPT_TX_PACKET_SIZE
> | and DCCP_SOCKOPT_RX_PACKET_SIZE. DCCP_SOCKOPT_PACKET_SIZE doesn't
> | work and packet size should be set independently on two half
> | connections.
> I disagree with this solution: it solves one problem by introducing two
> new ones:
>
> * the options are redundant:
> --at the sender the packet size is implicitly communicated via the
> `len' argument of dccp_sendmsg()
> --the receiver samples the packet sizes of incoming packets
The "intended average packet size", a congestion control parameter used by
CCID 3 and CCID 4, is different from the actually _observed_ packet size. I
could see how an explicit setting for this congestion control parameter might
be useful in addition to the information communicated by 'len' and incoming
packet sizes.
CCID 3, for example, says that 's' MAY be calculated from a running average,
OR from the maximum segment size. I think an option like
DCCP_SOCKOPT_TX_PACKET_SIZE, by which the app can declare an intended average
packet size, is also acceptable.
In practice CCID 2 won't make use of these parameters, and neither will most
CCID 3 receivers. But Ian is right that this is a per-half-connection variable.
> * it makes the programming interface more complex; currently these options
> only work for CCID 3 (cf. patch 6/7)
Don't understand this objection.
> * both CCID 2/3 are for fixed-packet sizes anyway, and the upcoming
> CCID 4 draft-ietf-dccp-tfrc-voip-05.txt looks much rather like a
> fixed `mini' packet size rather than a variable-size protocols
This is not right. We expected CCID 2 and CCID 3 senders to vary their packet
sizes due to application constraints. DCCP implementations SHOULD NOT require
sending apps to limit themselves to a single packet size. CCID 2 and 3 are
NOT intended for apps that vary their packet size *in response to congestion*,
but this is a different kettle of fish.
> * for varying packet sizes, the sender should calculate the mean/avg
> packet size by itself, rather than relying on information. For TFRC,
> [draft-floyd-rfc3448bis-00, sec. 4.1] suggests here:
> "where the segment size varies depending on the data, the sender MAY estimate the
> segment size s as the average segment size over the last four loss intervals."
See above.
> In summary, I think it would be better to let the sender/receiver determine the
> packet size from already available data. That is, derive s from the `len' of dccp_sendmsg(),
> and use a weighted-average mechanism like
> s = q * len + (1-q) * s
> to smooth out variations: in accordance with draft-floyd-rfc3448bis-00.
This would be fine with me, and perhaps even preferable in terms of the
programming API. But the drafts I think would allow the socket option, so if
it's needed now, why not?
Eddie
> -- Gerrit
> -
> To unsubscribe from this list: send the line "unsubscribe dccp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 5/7] [DCCP]: Introduce two new socket options
@ 2006-09-22 16:56 ` Eddie Kohler
0 siblings, 0 replies; 12+ messages in thread
From: Eddie Kohler @ 2006-09-22 16:56 UTC (permalink / raw)
To: Gerrit Renker
Cc: Ian McDonald, Arnaldo de Melo, David Miller, dccp (vger), netdev
Hi, just a couple clarifications and notes. I haven't deeply thought through
the new socket options, but disagree with your objections :)
Gerrit Renker wrote:
> | This creates two new socket options DCCP_SOCKOPT_TX_PACKET_SIZE
> | and DCCP_SOCKOPT_RX_PACKET_SIZE. DCCP_SOCKOPT_PACKET_SIZE doesn't
> | work and packet size should be set independently on two half
> | connections.
> I disagree with this solution: it solves one problem by introducing two
> new ones:
>
> * the options are redundant:
> --at the sender the packet size is implicitly communicated via the
> `len' argument of dccp_sendmsg()
> --the receiver samples the packet sizes of incoming packets
The "intended average packet size", a congestion control parameter used by
CCID 3 and CCID 4, is different from the actually _observed_ packet size. I
could see how an explicit setting for this congestion control parameter might
be useful in addition to the information communicated by 'len' and incoming
packet sizes.
CCID 3, for example, says that 's' MAY be calculated from a running average,
OR from the maximum segment size. I think an option like
DCCP_SOCKOPT_TX_PACKET_SIZE, by which the app can declare an intended average
packet size, is also acceptable.
In practice CCID 2 won't make use of these parameters, and neither will most
CCID 3 receivers. But Ian is right that this is a per-half-connection variable.
> * it makes the programming interface more complex; currently these options
> only work for CCID 3 (cf. patch 6/7)
Don't understand this objection.
> * both CCID 2/3 are for fixed-packet sizes anyway, and the upcoming
> CCID 4 draft-ietf-dccp-tfrc-voip-05.txt looks much rather like a
> fixed `mini' packet size rather than a variable-size protocols
This is not right. We expected CCID 2 and CCID 3 senders to vary their packet
sizes due to application constraints. DCCP implementations SHOULD NOT require
sending apps to limit themselves to a single packet size. CCID 2 and 3 are
NOT intended for apps that vary their packet size *in response to congestion*,
but this is a different kettle of fish.
> * for varying packet sizes, the sender should calculate the mean/avg
> packet size by itself, rather than relying on information. For TFRC,
> [draft-floyd-rfc3448bis-00, sec. 4.1] suggests here:
> "where the segment size varies depending on the data, the sender MAY estimate the
> segment size s as the average segment size over the last four loss intervals."
See above.
> In summary, I think it would be better to let the sender/receiver determine the
> packet size from already available data. That is, derive s from the `len' of dccp_sendmsg(),
> and use a weighted-average mechanism like
> s = q * len + (1-q) * s
> to smooth out variations: in accordance with draft-floyd-rfc3448bis-00.
This would be fine with me, and perhaps even preferable in terms of the
programming API. But the drafts I think would allow the socket option, so if
it's needed now, why not?
Eddie
> -- Gerrit
> -
> To unsubscribe from this list: send the line "unsubscribe dccp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 5/7] [DCCP]: Introduce two new socket options
2006-09-22 2:30 ` Ian McDonald
` (2 preceding siblings ...)
(?)
@ 2006-09-22 17:28 ` Gerrit Renker
-1 siblings, 0 replies; 12+ messages in thread
From: Gerrit Renker @ 2006-09-22 17:28 UTC (permalink / raw)
To: dccp
Hi Eddie,
| The "intended average packet size", a congestion control parameter used by
| CCID 3 and CCID 4, is different from the actually _observed_ packet size. I
| could see how an explicit setting for this congestion control parameter might
| be useful in addition to the information communicated by 'len' and incoming
| packet sizes.
|
| CCID 3, for example, says that 's' MAY be calculated from a running average,
| OR from the maximum segment size. I think an option like
| DCCP_SOCKOPT_TX_PACKET_SIZE, by which the app can declare an intended average
| packet size, is also acceptable.
It is acceptable but not useful. The kernel module already has the information
available to derive `s' in either way:
* it knows the maximum segment size (which a user would have to retrieve via another
socket option call)
* it has information about packet header lengths and option lengths
* it can track the average of past payload lengths
Why burden the application programmer to handcode an estimation of the average each
time? I can not see a justification for this, certainly not for CCIDs which
are intended to be used with (on average) fixed packet sizes.
I think that a priority is to keep the user programming interface as simple as
possible -- like UDP's interface, as stated in RFC 4340.
| > In summary, I think it would be better to let the sender/receiver determine the
| > packet size from already available data. That is, derive s from the `len' of dccp_sendmsg(),
| > and use a weighted-average mechanism like
| > s = q * len + (1-q) * s
| > to smooth out variations: in accordance with draft-floyd-rfc3448bis-00.
|
| This would be fine with me, and perhaps even preferable in terms of the
| programming API. But the drafts I think would allow the socket option, so if
| it's needed now, why not?
To encourage programmers to use DCCP by providing a simple-to-use programming API with a minimal
set of required options to program into the application code.
Gerrit
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH 5/7] [DCCP]: Introduce two new socket options
2006-09-22 2:30 ` Ian McDonald
` (3 preceding siblings ...)
(?)
@ 2006-09-22 17:35 ` Eddie Kohler
-1 siblings, 0 replies; 12+ messages in thread
From: Eddie Kohler @ 2006-09-22 17:35 UTC (permalink / raw)
To: dccp
> Why burden the application programmer to handcode an estimation of the average each
> time? I can not see a justification for this, certainly not for CCIDs which
> are intended to be used with (on average) fixed packet sizes.
>
> I think that a priority is to keep the user programming interface as simple as
> possible -- like UDP's interface, as stated in RFC 4340.
But if DCCP_SOCKOPT_TX_PACKET_SIZE defaults to the MSS, which the drafts
explicitly allow, then there's no burden on the application programmer.
Hopefully this is my last mail on this subject; I do not think it is that
important. The option seems potentially useful and not a huge burden.
Calculating the average would be good too. But we do not have a patch for
that at the moment.
Eddie
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH 5/7] [DCCP]: Introduce two new socket options
2006-09-22 2:30 ` Ian McDonald
` (4 preceding siblings ...)
(?)
@ 2006-09-22 17:49 ` Gerrit Renker
-1 siblings, 0 replies; 12+ messages in thread
From: Gerrit Renker @ 2006-09-22 17:49 UTC (permalink / raw)
To: dccp
Quoting Eddie Kohler:
| > Why burden the application programmer to handcode an estimation of the average each
| > time? I can not see a justification for this, certainly not for CCIDs which
| > are intended to be used with (on average) fixed packet sizes.
| >
| > I think that a priority is to keep the user programming interface as simple as
| > possible -- like UDP's interface, as stated in RFC 4340.
|
| But if DCCP_SOCKOPT_TX_PACKET_SIZE defaults to the MSS, which the drafts
| explicitly allow, then there's no burden on the application programmer.
This is a good input and should be related to patch 6/7 in which the default setting is
the standard size packet of 256 bytes; so maybe we should use MSS (or an estimate of it) there.
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH 5/7] [DCCP]: Introduce two new socket options
2006-09-22 2:30 ` Ian McDonald
` (5 preceding siblings ...)
(?)
@ 2006-11-16 13:57 ` Arnaldo Carvalho de Melo
-1 siblings, 0 replies; 12+ messages in thread
From: Arnaldo Carvalho de Melo @ 2006-11-16 13:57 UTC (permalink / raw)
To: dccp
On 9/22/06, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> Quoting Eddie Kohler:
> | > Why burden the application programmer to handcode an estimation of the average each
> | > time? I can not see a justification for this, certainly not for CCIDs which
> | > are intended to be used with (on average) fixed packet sizes.
> | >
> | > I think that a priority is to keep the user programming interface as simple as
> | > possible -- like UDP's interface, as stated in RFC 4340.
> |
> | But if DCCP_SOCKOPT_TX_PACKET_SIZE defaults to the MSS, which the drafts
> | explicitly allow, then there's no burden on the application programmer.
> This is a good input and should be related to patch 6/7 in which the default setting is
> the standard size packet of 256 bytes; so maybe we should use MSS (or an estimate of it) there.
Hi Folks, could Ian or Gerrit respin these patches to reflect what was
discussed here? Perhaps we can get this merged in 2.6.20 if we get
this done and tested before the merge window closes.
Thanks,
- Arnaldo
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH 5/7] [DCCP]: Introduce two new socket options
2006-09-22 2:30 ` Ian McDonald
` (6 preceding siblings ...)
(?)
@ 2006-11-16 14:07 ` Gerrit Renker
-1 siblings, 0 replies; 12+ messages in thread
From: Gerrit Renker @ 2006-11-16 14:07 UTC (permalink / raw)
To: dccp
Quoting Arnaldo Carvalho de Melo:
| On 9/22/06, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
| > Quoting Eddie Kohler:
| > | > Why burden the application programmer to handcode an estimation of the average each
| > | > time? I can not see a justification for this, certainly not for CCIDs which
| > | > are intended to be used with (on average) fixed packet sizes.
| > | >
| > | > I think that a priority is to keep the user programming interface as simple as
| > | > possible -- like UDP's interface, as stated in RFC 4340.
| > |
| > | But if DCCP_SOCKOPT_TX_PACKET_SIZE defaults to the MSS, which the drafts
| > | explicitly allow, then there's no burden on the application programmer.
| > This is a good input and should be related to patch 6/7 in which the default setting is
| > the standard size packet of 256 bytes; so maybe we should use MSS (or an estimate of it) there.
|
| Hi Folks, could Ian or Gerrit respin these patches to reflect what was
| discussed here? Perhaps we can get this merged in 2.6.20 if we get
| this done and tested before the merge window closes.
I am working on this, hope to have patch ready by end of next week.
Gerrit
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH 5/7] [DCCP]: Introduce two new socket options
2006-09-22 2:30 ` Ian McDonald
` (7 preceding siblings ...)
(?)
@ 2006-11-16 14:09 ` Arnaldo Carvalho de Melo
-1 siblings, 0 replies; 12+ messages in thread
From: Arnaldo Carvalho de Melo @ 2006-11-16 14:09 UTC (permalink / raw)
To: dccp
On 11/16/06, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> Quoting Arnaldo Carvalho de Melo:
> | On 9/22/06, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> | > Quoting Eddie Kohler:
> | > | > Why burden the application programmer to handcode an estimation of the average each
> | > | > time? I can not see a justification for this, certainly not for CCIDs which
> | > | > are intended to be used with (on average) fixed packet sizes.
> | > | >
> | > | > I think that a priority is to keep the user programming interface as simple as
> | > | > possible -- like UDP's interface, as stated in RFC 4340.
> | > |
> | > | But if DCCP_SOCKOPT_TX_PACKET_SIZE defaults to the MSS, which the drafts
> | > | explicitly allow, then there's no burden on the application programmer.
> | > This is a good input and should be related to patch 6/7 in which the default setting is
> | > the standard size packet of 256 bytes; so maybe we should use MSS (or an estimate of it) there.
> |
> | Hi Folks, could Ian or Gerrit respin these patches to reflect what was
> | discussed here? Perhaps we can get this merged in 2.6.20 if we get
> | this done and tested before the merge window closes.
> I am working on this, hope to have patch ready by end of next week.
Great, look forward for the changesets,
- Arnaldo
^ permalink raw reply [flat|nested] 12+ messages in thread