RFD: Ack Vectors

RFD: Ack Vectors

[Gerrit Renker]

|          * the spec and the code allow to have different CCIDs for forward and return path;
|          * this is foremost a theoretical thing - it is like having e.g. TCP Reno for the data and
|            TCP Hybla for the Acks that come back;
|          * but the practical implementation causes no end of headaches:
|            - With regard to Ian's suggestion, Ack Vectors must be enabled if at least one CCID is CCID2.
|            - If CCID2 talks to CCID3 then CCID2 will want to have its Ack Vectors from the CCID3 peer.
|              However, there is no CCID3 code to support Ack Vectors at the moment (and in the spec this
|              is only implicit).
|            - If CCID3 talks to CCID2 then CCID3 will want its X_recv and loss rate from the CCID2 peer.
|              But how? CCID2 doesn't know these things.
The above is not correct, so please forget it. Furthermore, code which assumes that TX/RX CCID are always
the same is ugly and will sooner or later break, so it is also not an option. 

With regard to the Ack Vectors, my suggestion however is
 * to remove the sysctl - it is confusing;
 * to make the use of Ack Vectors dependent on the current RX CCID;
 * 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;
 * optional and for debugging: disabling of Ack Vectors in the Kconfig menu.

Re: RFD: Ack Vectors

[Ian McDonald]

On 7/30/07, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> 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.

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

Ian
-- 
Web1: http://wand.net.nz/~iam4/
Web2: http://www.jandi.co.nz
Blog: http://iansblog.jandi.co.nz

Re: RFD: Ack Vectors

[Gerrit Renker]

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? 

Re: RFD: Ack Vectors

[Ian McDonald]

On 8/2/07, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> 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.
>

Well I think the discussion is useful as a future reference. There's
no hurry on any of this really.

> |  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?
>
Data Dropped is more when receiver gets it but discards for some
reason as I read it.

Ian
-- 
Web1: http://wand.net.nz/~iam4/
Web2: http://www.jandi.co.nz
Blog: http://iansblog.jandi.co.nz