DCCP protocol discussions
 help / color / mirror / Atom feed
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? 

  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