RFD: Ack Vectors
| * 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.
Quoted 2 lines · Gerrit Renker
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.
Quoted 1 line
* 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....
Quoted 2 lines
* 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.
Quoted 2 lines
* optional and for debugging: disabling of Ack Vectors in the
Kconfigmenu.
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
Signature · 3 lines
Web1: http://wand.net.nz/~iam4/ Web2: http://www.jandi.co.nz Blog: http://iansblog.jandi.co.nz
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?
Quoted 7 lines · Gerrit Renker
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.
Quoted 6 lines
| 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
Signature · 3 lines
Web1: http://wand.net.nz/~iam4/ Web2: http://www.jandi.co.nz Blog: http://iansblog.jandi.co.nz