From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
To: dccp@vger.kernel.org
Subject: Re: [PATCH 5/7] [DCCP]: Introduce two new socket options
Date: Fri, 22 Sep 2006 17:28:01 +0000 [thread overview]
Message-ID: <200609221828.02122@strip-the-willow> (raw)
In-Reply-To: <200609221430.14555.ian.mcdonald@jandi.co.nz>
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
next prev parent reply other threads:[~2006-09-22 17:28 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-22 2:30 [PATCH 5/7] [DCCP]: Introduce two new socket options Ian McDonald
2006-09-22 2:30 ` Ian McDonald
2006-09-22 10:37 ` Gerrit Renker
2006-09-22 10:37 ` Gerrit Renker
2006-09-22 16:56 ` Eddie Kohler
2006-09-22 16:56 ` Eddie Kohler
2006-09-22 17:28 ` Gerrit Renker [this message]
2006-09-22 17:35 ` Eddie Kohler
2006-09-22 17:49 ` Gerrit Renker
2006-11-16 13:57 ` Arnaldo Carvalho de Melo
2006-11-16 14:07 ` Gerrit Renker
2006-11-16 14:09 ` Arnaldo Carvalho de Melo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200609221828.02122@strip-the-willow \
--to=gerrit@erg.abdn.ac.uk \
--cc=dccp@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.