Hi Christian, I would like to mention that the previous email was my own opinion (i.e., I am not sure if these are officially agreed in the DCCP group). >>> may I ask a simply question? Is it possible to send DCCP packets >>> at other times than those calculated by the rate control? I mean, >>> is it possible to call a send socket call with an option saying, >>> send this packet immediately no matter that the rate control is >>> saying to you? >>> >> In my opinion and experience, this is possible - after all, DCCP >> calculates the *suggested* sending rate. > > Cool. Thus, I just have to change the ccid3_hc_tx_packet_sent > function in ccid3.c. If, for example, a packet is mark as urgent > (somehow), then I can drop the scheduling of packet transmission [RFC > 3448, 4.6] but send the packet immediately? > Perhaps, yes. I would think, however, that your additional mechanism might need some sort of agreement/consensus in the DCCP group, if you were to change ccid3_hc_tx_packet method. Alternatively, you could make your additional mechanism as a choice of an application, if there is a way (i.e., it could be an implementation choice at an application level). >>> >>> The background of my questions is based on the experience, that >>> real-time packets shall be send immediately, especially if a >>> scenario of very interactivity is given, and that some codecs >>> cannot change their sending rate immediately but need some extra >>> time (e.g. one or two additional frame periods). Thus, a less >>> strict sending schedule would help. >>> >> >> You might want to change the codec itself to interact with DCCP in >> real time, so that the codec can change the necessary parameters >> (e.g., various encoding parameters) when needed. > > Yes, that is what we are doing. However, due to calculation speed and > queuing, this cannot happen immediately but only with a slight delay. > Also, we need to support a frame size of 2.5 ms instead of 10ms. This > should be still ok? > I am not quite sure what are the requirements of your applications, but the earlier email today from Ingemar might be relevant/helpful to this question. Thanks, Soo-Hyun
