Hi Soo-Hyun Choi, >> 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? > For example, the calculated inter-packet interval is 0.1 ms over a > general purpose PC (installed a modern Linux kernel). Also, assume the > host OS clock granularity is 4 ms (i.e., 250 Hz) - well, some Linux > kernels have configured at higher rate than this but not more than > 1000 Hz. Then, there would be the cases that the OS clock did not > schedule the real-time application in time such that the application > cannot actually maintain the calculated inter-packet interval correctly. > > When the application is scheduled next time, the application would > need to send the packets which have not been able to transmitted due > to the OS clock granularity. > > Caveat: > What we need to be careful is that the application should not send > much faster than the DCCP rate, because it may introduce (unwanted) > persistent packet losses. As we know, the packet losses can degrade > the performance of the multimedia applications significantly. Yes, of course. > > >> The role of DCCP would be to calculate the proposed sending rate and >> to measure the network round trip time. This data is then used by an >> application specific rate control. > > Correct. > >> >> 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? Anyhow, thanks for the fast and excellent answer. Greetings Christian
