| > I stumbled over two things and can make no sense of a bit of CCID 3 Receive code:
| >
| > 1) ccid3_hc_rx_sock maintains a real-timer RTT counter ccid3hcrx_rtt
| > which is an alias for a TFRC structure defined in <linux/tfrc.h>
|
| See comments below. Don't really understand what you are saying.
Sorry if my questions were really clear, part of this is probably due to my lack of understanding
what went on. I went through this again and I hope that this time it is clearer to understand.
1) The above was expressed in too complicated a way. I meant to say "why does the receiver
keep a real-time RTT counter"? I was referrind to the following element of code:
struct ccid3_hc_rx_sock {
struct tfrc_rx_info ccid3hcrx_tfrc;
/* ... */
#define ccid3hcrx_rtt ccid3hcrx_tfrc.tfrcrx_rtt
And in <linux/tfrc.h>:
struct tfrc_tx_info {
/* ... */
__u32 tfrctx_rtt;
I was puzzled why the receiver has to keep time while RFC 4342 speaks of `quarter RTT increases'
For `pure' TFRC (:-) it is understandable why the receiver should track RTT, here I could not follow.
2) With regard to the code I was referring to, the points are precisely:
* the receiver appears not to look at the window counter
* RTT is updated only on Ack/DataAck and is never updated when the packet carries no timestamp, due to:
case DCCP_PKT_ACK:
if (hcrx->ccid3hcrx_state == TFRC_RSTATE_NO_DATA)
return;
case DCCP_PKT_DATAACK:
if (opt_recv->dccpor_timestamp_echo == 0)
break;
* timestamps are permitted on any DCCP packet (RFC 4340, sec. 13); hence the code, if it is
really used, could be pulled out and below the switch statement, to also use the timestamps
of incoming Data packets
* if I understand correctly, ccid3_hc_rx_packet_recv is in the receiving side of the
half-connection ==> receiver gets data and sends Acks
==> but only receives (Data)Acks if it is also a sender or if it
has to ack e.g. AckVectors
* the thing that puzzled me most is that ccid3_hc_tx_send_packet() uses the window counter as
per RFC 4342 8.1 (visible in wireshark), but the receiver makes no use of it.
| > 2) ccid3_hc_rx_packet_recv (detailed below) updates this, but leaves the variable
| > `win_count = packet->dccphrx_ccval;' entirely untouched after initialisation
| >
| This can be deleted. It was used but I have shifted the code into
| ccid3_hc_rx_detect_loss. I forgot to delete this variable. I will
| produce a patch to do this in next week if you don't.
Do you mean another function - I can not find any RTT-related code in ccid3_hc_rx_detect_loss.
| > /*
| > after updating r_sample with regard to t_elapsed ...
| > ==> The code that now follows is identical with ccid3_hc_tx_packet_recv
| > --is this a leftover ?
| > --should it not rather update the sending structure (ccid3hctx_rtt)
|
| No they are half connections. Maybe I don't understand your question.
Again, sorry for not putting this clearly: my understanding is that currently the code works
unidirectional, i.e. a node is not both receiver and sender at the same time. This would be the most
sensible starting point; and in that case the above question is unnecessary.
| > ==> why not use win_count ??
|
| Can be deleted.
My intuition at the moment is that it should be the other way round (i.e. delete the timestamp-dependent code
and use window counter values as per RFC 4342): in any case I think this needs a revision.
I have been doing some capturing tests to solve this question today, but ran out of time.
Another ToDo.
-- Gerrit
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
