[PATCH 5/7] [DCCP]: Introduce two new socket options

[PATCH 5/7] [DCCP]: Introduce two new socket options

[Ian McDonald]

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
 

[PATCH 5/7] [DCCP]: Introduce two new socket options

[Ian McDonald]

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
 

Re: [PATCH 5/7] [DCCP]: Introduce two new socket options

[Gerrit Renker]

|  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

Re: [PATCH 5/7] [DCCP]: Introduce two new socket options

[Gerrit Renker]

|  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

Re: [PATCH 5/7] [DCCP]: Introduce two new socket options

[Eddie Kohler]

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

Re: [PATCH 5/7] [DCCP]: Introduce two new socket options

[Eddie Kohler]

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

Re: [PATCH 5/7] [DCCP]: Introduce two new socket options

[Gerrit Renker]

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

Re: [PATCH 5/7] [DCCP]: Introduce two new socket options

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

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

Re: [PATCH 5/7] [DCCP]: Introduce two new socket options

[Gerrit Renker]

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.

Re: [PATCH 5/7] [DCCP]: Introduce two new socket options

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

Thanks,

- Arnaldo

Re: [PATCH 5/7] [DCCP]: Introduce two new socket options

[Gerrit Renker]

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

Re: [PATCH 5/7] [DCCP]: Introduce two new socket options

[Arnaldo Carvalho de Melo]

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