From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
To: dccp@vger.kernel.org
Subject: Re: RFD: Ack Vectors
Date: Wed, 01 Aug 2007 16:18:36 +0000 [thread overview]
Message-ID: <200708011718.37036@strip-the-willow> (raw)
In-Reply-To: <200707300934.36798@strip-the-willow>
Quoting Ian McDonald:
| > With regard to the Ack Vectors, my suggestion however is
| > * to remove the sysctl - it is confusing;
|
| Agree in current form provided the next bullet point is carried out.
|
| > * to make the use of Ack Vectors dependent on the current RX CCID;
|
| It should be on for CCID2, off for CCID3. It is required for CCID2
| according to RFC4341. It is optional for CCID3 according to RFC4342.
| However last time I checked with our CCID3 it breaks it. I haven't
| checked recently though....
|
| > * the TX CCID need not be considered for the Ack Vector allocation, since the `Send Ack Vector'
| > feature is server-priority (RFC 4340, 6.4) and thus negotiated by the side which has the RX CCID;
|
| OK.
Omission on my side - I have just checked and found out that the negotiation of the "Send ack vector
feature" is not yet implemented. It is not something which can be done with a hack, since the CCIDs
can also be negotiated, so that enabling Ack Vectors depends on the end result of negotiating the
CCID.
I think at the moment we should add this as a ToDo. If I get some time I'll try to implement the
above, but it is more work than anticipated and so depends on available time.
| > * optional and for debugging: disabling of Ack Vectors in the Kconfig menu.
| >
| This implies it is on by default. I think it should be off by default
| for CCID3.
This is resolved, since the Kconfig implementation was quite cleverly done (not by me):
config IP_DCCP_CCID2
tristate "CCID2 (TCP-Like) (EXPERIMENTAL)"
depends on IP_DCCP
def_tristate IP_DCCP
select IP_DCCP_ACKVEC
=> When CCID2 is enabled, then support for Ack Vectors is automatically compiled in.
(I would like to return in the discussion to the `Null CCID' issue and will send RFC).
As said, auto-disabling Ack Vectors depending on the CCID is a bit more complicated than
anticipated.
| The information is not actually needed from an ack vector
| and actually creates more traffic. It seems like
| draft-kohler-dccp-ccid3-drops-01.txt is a replacement for ack vectors
| in CCID3 if you need extra info.
Never figured that one out - doesn't the Data Dropped option do the same thing?
next prev parent reply other threads:[~2007-08-01 16:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-30 8:34 RFD: Ack Vectors Gerrit Renker
2007-07-31 21:16 ` Ian McDonald
2007-08-01 16:18 ` Gerrit Renker [this message]
2007-08-01 22:12 ` Ian McDonald
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=200708011718.37036@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox