Re: [dccp] Problems with DCCP CCID3
On Sat, Dec 27, 2008 at 11:25 AM, Vitor Bernardo vmb...@student.dei.uc.pt wrote: Hello, I will wait for Alessio Botta reply before asking in DCCP Linux mailing, because I think that the problem could be with D-ITG. An application should not cause the operating system kernel to crash so that needs to be fixed, even if there is a problem with D-ITG. -- Web: http://wand.net.nz/~iam4/, http://www.jandi.co.nz Blog: http://iansblog.jandi.co.nz
Re: [dccp] [RFC] dccp ccid-3: High-res or low-res timers?
On Tue, Nov 18, 2008 at 7:14 PM, Gerrit Renker [EMAIL PROTECTED] wrote: | The RFC uses an example of 1 msec scheduling and 0.1 msec RTT. However | what would be worse is devices on a LAN with 10 msec timer - e.g. two | embedded devices at home - I haven't done the maths but I think the | rate achievable would be quite low. If we use lower-resolution timers I think there should be a recommendation (in the Kconfig menu for instance) not to use low HZ values. Previously this was done as a build warning, but it is annoying if people do an allmodconfig and are not otherwise interested in DCCP. Agree Do you think we could live with clamping the RTT to some sensible minimum, since on a local LAN the use of congestion control is questionable? I was thinking in the order of 0.5 ... 1msec. I think that is a good idea - if 1 msec, and HZ = 1000 then we wouldn't lose any transmission capability. | Thinking laterally there is another possible solution - something I | used way back in the 80s for another project - build your own | scheduler! We could set a high resolution timer to tick every 0.1 msec | and then use the coarse grained algorithm at that point | So we have three possible options - timer-based (low/high), and your suggestion above. We can keep these variants open by spawning an experimental subtree which provides an alternative implementation, so that people could explore alternative algorithms, compare and send patches. For production use the low-resolution variant is the simplest and less expensive option, and it is good that there is consensus about it. Yes - and with your RTT clamping then no need to do my idea around scheduler. In a discussion about two years ago there was another idea, doing away with the nofeedback timer, by checking the nofeedback time at the instant a packet is sent. I think this is useful as reduces the amount of timers going off, which reduces system load. -- Web: http://wand.net.nz/~iam4/, http://www.jandi.co.nz Blog: http://iansblog.jandi.co.nz
Re: [dccp] draft-phelan-dccp-natencap-00.txt
On Fri, Feb 15, 2008 at 1:42 PM, Dan Wing [EMAIL PROTECTED] wrote: I am guessing/hoping that Rémi's draft-denis-behave-nat-dccp-00.txt documents what the Linux DCCP NAT code does? The BEHAVE working group has a milestone to adopt a DCCP NAT document, and draft-denis-behave-nat-dccp-00.txt is the only candidate document at this point. Can you point me at that? Ian -- Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz
Re: [dccp] DCCP stack source code
On 12/6/07, Ingemar Johansson S [EMAIL PROTECTED] wrote: Hi I am interested in DCCP stack source code for a student project, the primary interest is CCID 4 preferrably with faster restart. I would therefore be greatful for pointers to the latest implementations . Additionally we plan to use MS-Windows as OS, I understand that most implementations are Linux kernel based. What is the experience (good or bad) regarding the combination MS Windows and DCCP. Regards Ingemar Hello Ingemar, I have seen no source code around for DCCP for Windows. There is source code for BSD around in public as well as DCCP. Two people are actively working on CCID4 for Linux so you may want to talk to them on [EMAIL PROTECTED] If you want to take it further you might want to talk to Jitendra Padhye who was a co-author of CCID3: http://research.microsoft.com/~padhye/ Also Vaishnav Janardhan seems to have worked on DCCP at Microsoft as an intern recently: http://research.microsoft.com/netres/interns.aspx http://www1.cs.columbia.edu/~vj2135/index.htm Hope this helps. Regards, Ian -- Web1: http://wand.net.nz/~iam4/ Web2: http://www.jandi.co.nz
[dccp] Re: About pluggable congestion control infrastructure in DCCP
On 8/20/07, Arnaldo Carvalho de Melo [EMAIL PROTECTED] wrote: Em Mon, Aug 20, 2007 at 08:53:15AM +1200, Ian McDonald escreveu: On 8/20/07, Shahiduzzaman [EMAIL PROTECTED] wrote: Hi all, This may be a redundant or very naive question - sorry in advance for that. Can anybody tell me, whether the current Linux kernel DCCP implementation is done in a fashion like TCP pluggable congestion avoidance modules infrastructure (http://lwn.net/Articles/128681/) ? The short answer is yes and no! I think the answer is just yes The CCID infrastructure in the Linux kernel is done in a fashion like the TCP pluggable congestion avoidances modules infrastructure. One can write a new CCID and load, making it available for userspace programs to use without changing a line of code in what is already in the kernel. No that the in-tree version does not support it. The question was if it was done in a fashion like, not exactly as. I may be confused with your answer as english is not my first language tho :-) I think my answer may have been confusing then... To clarify the CCID code is modular in that you don't need to write the code from the ground up for a new CCID. It has callback functions for implementing various protocol requirements. The part where it is not modular (in the tree anywhere) is if you want to change just the very small part of how the congestion control is done for any particular CCID. I hope this clarifies a little. I get confused even though English is my first language! Ian -- Web1: http://wand.net.nz/~iam4/ Web2: http://www.jandi.co.nz Blog: http://iansblog.jandi.co.nz
Re: [dccp] Comments on FR draft -03
On 8/1/07, Gorry Fairhurst [EMAIL PROTECTED] wrote: Simulations are needed, and three of the issues I'd like to understand are: 1) What is the best time-constant used for decay of the max receive rate allowed by FR? I think the case for the periods used in the draft to maintain the window are not justified - either by need to cater for 30 minutes of idleness, nor the safety of this case. In my mind, this is an issue that should be thought upon, since the longer the value the more the case that this should be experimental. In my mind, I wonder if much smaller periods would be acceptable for typical applications - such as video-conference sessions (e.g. by thinking on different periods of idleness)? I noticed this as well. 30 minutes of idleness is a long time. In my opinion 3 minutes would be plenty for most applications! Ian -- Web1: http://wand.net.nz/~iam4/ Web2: http://www.jandi.co.nz Blog: http://iansblog.jandi.co.nz
Re: [dccp] I-D ACTION:draft-ietf-dccp-tfrc-faster-restart-03.txt
On 7/24/07, Sally Floyd [EMAIL PROTECTED] wrote: Have started work on implementing this for Linux now. Oh good. You should take note of the bugfix in the slides, at http://www.icir.org/floyd/talks/fasterstart-jul07.pdf, .ppt Yes I saw that, thanks. The current inclination of the authors is to ditch the ping during idle intervals, so if you have any feedback, that would be great. Yes I agree - pings make the implementation much more complex. I'm not intending to implement them. The big need for Faster Restart is simulations/experiments to make sure that the burden imposed by the extra aggressiveness does not lead to any completely dire consequences during times of high congestion (e.g., when everyone is bursty, everyone has idle periods, and everyone is using Faster Restart...) My tests probably won't be so much in this area. More around the area - does it help with media after times of idle, where currently they get hit hard. Others can use the code, of course, to do their own experiments. Take care, - Sally http://www.icir.org/floyd/ Regards, Ian -- Web1: http://wand.net.nz/~iam4/ Web2: http://www.jandi.co.nz Blog: http://iansblog.jandi.co.nz
Re: [dccp] Adopt draft-fairhurst-dccp-serv-codes-03.txt?
On 3/27/07, Phelan, Tom [EMAIL PROTECTED] wrote: Hi All, In Prague, there seemed to be (very) strong support for adopting Gorry's Service Codes draft (draft-fairhurst-dccp-serv-codes-03.txt) as a working group item. For those who weren't there, this is an opportunity to state your opinion. Of course, we're mainly looking for anyone who has a contrary opinion, but those that favor adoption please speak up too, so that we'll know someone is listening :-). I agree. Note that comments on the content of the document are appreciated also. Comments sent in another email two days ago. Tom P. Ian -- Web: http://wand.net.nz/~iam4 Blog: http://iansblog.jandi.co.nz WAND Network Research Group
Re: [dccp] feedback on draft-floyd-dccp-ccid4-00.txt?
On 3/19/07, Sally Floyd [EMAIL PROTECTED] wrote: Thanks. Done. Section 5: Unlike CCID 3, the CCID 4 sender enforces a minimum interval of 10 ms between data packets, regardless of the allowed transmit rate. I think we need clarification here. Are we saying on average we should maintain a minimum interval of 10 ms. Think of an OS where timeslices 100 times a second (not uncommon). Now DCCP CCID4 might get time at (referencing from 0) 1, 11, 20, 33, 41. Should we be able to send each time slice (I think so) or do we say at 20 and 41 we can't because not 10 msec? Maybe we should say not more than an average of 10 milliseconds over some time frame (500 milliseconds ??) when actively transmitting. If a DCCP sender is generally going to be able to send packets infrequently, say, with something like 100 ms between packets because of OS timeslices, then I don't think the sender should be preparing small data packets and sending ten or so small packets every time it gets a timeslice. It would make more sense, in this case, for the sender to be sending larger packets, less frequently (since it already has the larger end-to-end delay of waiting 100 ms, sometimes, to send small packets). However, that said, I agree that we do need to add some text about sometimes sending two or three small packets at once, because of the constraints of OS timing. But I don't want to say that the sender gets to routinely send 50 small packets back-to-back - that wouldn't make sense to me. Suggestions on language? Section 5: Old: Unlike CCID 3, the CCID 4 sender enforces a minimum interval of 10 ms between data packets, regardless of the allowed transmit rate. New: Unlike CCID 3, the CCID 4 sender enforces a minimum interval of 10 ms between data packets, regardless of the allowed transmit rate. If operating system scheduling granularity makes this impractical up to one additional packet MAY be sent per timeslice providing that no more than three packets are sent in any 30 ms interval. Section 5.1: 5.1. Response to Idle and Application-limited Periods This is described in Section 5.1 of [RFC4342]. I think we should consider faster restart here. I agree, but I don't necessarily want to hold up this document for faster restart. I think that faster restart has to proceed at its own pace. Understand. However remember VoIP will be more susceptible to this then other apps as it often employs silence supression. Perhaps in an RFC tracking section you can say that an implementor MAY track faster restart before an explicit update to the RFC? Ian -- Web: http://wand.net.nz/~iam4 Blog: http://iansblog.jandi.co.nz WAND Network Research Group
Re: [dccp] feedback on draft-floyd-dccp-ccid4-00.txt?
On 3/7/07, Sally Floyd [EMAIL PROTECTED] wrote: The internet-draft Profile for DCCP Congestion Control ID 4: the Small-Packet Variant of TFRC Congestion Control, aka CCID 4, is available from http://www.ietf.org/internet-drafts/draft-floyd-dccp-ccid4-00.txt; Looks good. A few comments. Comments: Section 5: Because CCID 4 is intended for applications that send small packets, the allowed transmit rate derived from the TCP throughput equation is reduced by a factor that accounts for packet header size, as specified in Section 4.2 of [TFRC-SP]. The header size on data packets is estimated as 32 bytes (20 bytes for the IP header, and 12 bytes for the DCCP-Data header with 24-bit sequence numbers). If the DCCP sender is sending N-byte data packets, the allowed transmit rate is reduced by N/(N+32). CCID 4 senders are limited to this fair rate. Should this be changed for 48 bit sequence numbers as this seems to be the default in implementations and with a note about if 24 bit sequence numbers are used. Section 5: Unlike CCID 3, the CCID 4 sender enforces a minimum interval of 10 ms between data packets, regardless of the allowed transmit rate. I think we need clarification here. Are we saying on average we should maintain a minimum interval of 10 ms. Think of an OS where timeslices 100 times a second (not uncommon). Now DCCP CCID4 might get time at (referencing from 0) 1, 11, 20, 33, 41. Should we be able to send each time slice (I think so) or do we say at 20 and 41 we can't because not 10 msec? Maybe we should say not more than an average of 10 milliseconds over some time frame (500 milliseconds ??) when actively transmitting. Section 5.1: 5.1. Response to Idle and Application-limited Periods This is described in Section 5.1 of [RFC4342]. I think we should consider faster restart here. Regards, Ian -- Web: http://wand.net.nz/~iam4 Blog: http://iansblog.jandi.co.nz WAND Network Research Group
Re: [dccp] Some comments on the draft of 3448/TFRC.bis (Feb 2007)
On 2/28/07, Gorry Fairhurst [EMAIL PROTECTED] wrote: 2) Ian - In section 4.3 of RFC3448 we have the equation for X as: If (p 0) Calculate X_calc using the TCP throughput equation. X = max(min(X_calc, 2*X_recv), s/t_mbi); I have been doing experiments where I deliberately drop real-time packets when I don't believe they will get to the other end before an expiry time. What happens though is that I can't then transmit packets later on due to the above equation as in practice it becomes X=2*X_recv and X_recv quickly goes close to 0 as it is the receive rate since last feedback. Feedback gets sent once per RTT I think and so if you don't send anything for one RTT you get X=s/t_mbi in effect which is 530/64 for my size packets - i.e. a sending rate of 10 bytes per second. In practice I don't get quite this bad as I don't drop off transmitting that long usually but I still definitely get penalised. -- After reading the draft 0.2 of TFRC faster restart I think that will solve many of my issues and issues other people will face. The question is whether the existing TFRC should be amended or whether people should just go ahead and implement TFRC faster restart. Either way I suspect TFRC faster restart would end up being the default. Ian -- Web: http://wand.net.nz/~iam4 Blog: http://iansblog.jandi.co.nz WAND Network Research Group
Re: [dccp] DCCP and iotcl
Patrick, I would recommend using 2.6.20 and applying the patches from my website or Gerrit's website. Then CCID3 behaves fairly well. If you are mainly planning to use CCID2 then 2.6.20 as is should be fine and I think 2.6.19 as well but either way you need to upgrade from 2.6.18. I've put a few more tips on my DCCP page at my webpage (in footer) and also some updated sample code. It is in the middle of another application of mine but you should be able to work it out. I'm not sure if that other code still works or not and don't have time to test/fix right now. As always I'm interested to hear what purpose people are using DCCP for so if you'd like to share that too it would be great. Ian On 2/23/07, patrick andrieux [EMAIL PROTECTED] wrote: Hi and thanks Ian, I'm using the simple client/server application : http://wand.net.nz/~iam4/dccp/dccp-cs-0.01.tar.bz2 I work on Debian etch with default linux kernel which is 2.6.18 for now. I hadn't apply any patches yet, but I'm doing it today... I patched dccp module with patches 1 to 6 with a similar command than below Unfortunately, the 7th (07-2b_ccid3_tx-len-not-needed.diff) doesn't work : /usr/src/linux-source-2.6.18# patch -p1 /tmp/patchDCCP/07-2b_ccid3_tx- len-not-needed.diff patching file net/dccp/ccids/ccid3.c Hunk #1 FAILED at 149. 1 out of 1 hunk FAILED -- saving rejects to file net/dccp/ccids/ccid3.c.rej Am I doing something wrong ? or is there any issues with this patch ? (and I guess the errors I get when I try the other patches come from this first problem) regards, Patrick. 2007/2/21, Ian McDonald [EMAIL PROTECTED]: On 2/22/07, patrick andrieux [EMAIL PROTECTED] wrote: Hi, I'm doing some research on DCCP, and I'm trying to use ioctl() function. I ran the sample code (from http://linux-net.osdl.org/index.php/DCCP_Testing ) using -proto TCP. I added a few lines to use ioctl(), and it works with TCP (return value is 0). Which sample code are you using? What version of Linux? Any extra patches? But it doesn't work with DCCP, I get -1 as return value. I took a look at DCCP source code, and basically my first step would be to display in the kernel log what dccp_ioctl() prints. My guess is that functionalities to use ioctl() are not implemented yet. am I right ? Is there any way to get some information from DCCP other than sysctl ? Yes - use dccp_probe. It's in the source code tree and also on the Wiki you were looking at. cc'd dccp@vger.kernel.org as this is where we can discuss more (as per Leandro) Ian -- Web: http://wand.net.nz/~iam4 Blog: http://iansblog.jandi.co.nz WAND Network Research Group - To unsubscribe from this list: send the line unsubscribe dccp in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Web: http://wand.net.nz/~iam4 Blog: http://iansblog.jandi.co.nz WAND Network Research Group
Re: [dccp] DCCP and iotcl
On 2/22/07, patrick andrieux [EMAIL PROTECTED] wrote: Hi, I'm doing some research on DCCP, and I'm trying to use ioctl() function. I ran the sample code (from http://linux-net.osdl.org/index.php/DCCP_Testing ) using -proto TCP. I added a few lines to use ioctl(), and it works with TCP (return value is 0). Which sample code are you using? What version of Linux? Any extra patches? But it doesn't work with DCCP, I get -1 as return value. I took a look at DCCP source code, and basically my first step would be to display in the kernel log what dccp_ioctl() prints. My guess is that functionalities to use ioctl() are not implemented yet. am I right ? Is there any way to get some information from DCCP other than sysctl ? Yes - use dccp_probe. It's in the source code tree and also on the Wiki you were looking at. cc'd dccp@vger.kernel.org as this is where we can discuss more (as per Leandro) Ian -- Web: http://wand.net.nz/~iam4 Blog: http://iansblog.jandi.co.nz WAND Network Research Group
Re: [dccp] Ack vector implementation notes
On 2/22/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello, I am now implementing Ack Veckitor and, while testing its operation according to Appendix A of RFC4340 (pages 118-119), I've run in some puzzle: Vladimir, Just a side note really. Which operating system are you implementing for? I though Linux had Ack Vectors already. Are you fixing them so they work better or are you working on another OS? Ian -- Web: http://wand.net.nz/~iam4 Blog: http://iansblog.jandi.co.nz WAND Network Research Group
Re: [dccp] TFRC minrate calculation after idle or datalimited period
On 2/16/07, Eddie Kohler [EMAIL PROTECTED] wrote: The X equation has not changed between RFC3448 and RFC3448bis. So RFC3448bis is, in standard compliance terms, irrelevant to RFC4342 implementations. It would be relevant to a later update of CCID3 of course. This is probably slightly off-topic but I thought I would comment anyway: In section 4.3 of RFC3448 we have the equation for X as: If (p 0) Calculate X_calc using the TCP throughput equation. X = max(min(X_calc, 2*X_recv), s/t_mbi); I have been doing experiments where I deliberately drop real-time packets when I don't believe they will get to the other end before an expiry time. What happens though is that I can't then transmit packets later on due to the above equation as in practice it becomes X=2*X_recv and X_recv quickly goes close to 0 as it is the receive rate since last feedback. Feedback gets sent once per RTT I think and so if you don't send anything for one RTT you get X=s/t_mbi in effect which is 530/64 for my size packets - i.e. a sending rate of 10 bytes per second. In practice I don't get quite this bad as I don't drop off transmitting that long usually but I still definitely get penalised. It's probably more a question of coming up with a different congestion control scheme (MFRC type thing) but thought I'd mention it in practice as implementation experience. Regards, Ian -- Web: http://wand.net.nz/~iam4 Blog: http://iansblog.jandi.co.nz WAND Network Research Group
Re: [dccp] TFRC minrate calculation after idle or datalimited period
On 2/16/07, Arjuna Sathiaseelan [EMAIL PROTECTED] wrote: Hi Ian, Some questions: 1)Do you drop the packets from the transmit buffer? Yes 2)Is X_recv = 0, since the sender does not send any packets? Potentially yes. If 1) and 2) right - isnt this an idle period scenario? It is an idle period scenario but looking through RFC3448 for idle I don't know if this one was envisaged as they don't mention it. Remember on a LAN this could knock back your rate in less than 1 millisecond. Or are u dropping packets in the middle after the sender has sent it? No Ian -- Web: http://wand.net.nz/~iam4 Blog: http://iansblog.jandi.co.nz WAND Network Research Group
[dccp] Re: [PATCH 2/5]: DCCP Recalc on non-loss intervals
One nit. If you are following RFC terminology i_tot0 should include non_loss, but in the code i_tot1 does. The code seems correct except for the switching of i_tot0 and i_tot1. Eddie You're right here and I think this is contributing to much of the confusion as I read through Gerrit's most recent emails. I'm reworking this patch at present and adding quite a few comments. Ian -- Web: http://wand.net.nz/~iam4 Blog: http://iansblog.jandi.co.nz WAND Network Research Group
[dccp] Re: [PATCH 2/5]: DCCP Recalc on non-loss intervals
On 1/5/07, Eddie Kohler [EMAIL PROTECTED] wrote: I am assuming however that the incomplete loss interval is NOT included in the 'hcrx-ccid3hcrx_li_hist' list. If that list DOES include the incomplete loss interval, then the code would need to be different. Correct. I don't quite get why one needs dccp_li_hist_recalc_recalcloss. One could do probably do that simpler, and maybe Ian can explain his reasoning. Why is it necessary at all? But RFC3448 does require that one use the incomplete loss interval in the i_tot calculations. The reason for this is if you are recalculating i_mean based on non loss you should check after every packet received. However this involves quite a lot of calculations on linked lists which are CPU intensive and also stall other processes potentially with locks being taken. So what I've done is looked at how many packets of non loss would be required to alter i_mean. This is then added to the current sequence number and stored in hist_recalc_recalcloss. I then just do a simple comparison on every packet to see if we've met this high water mark. One nit. If you are following RFC terminology i_tot0 should include non_loss, but in the code i_tot1 does. The code seems correct except for the switching of i_tot0 and i_tot1. I'll look into that when I get a chance. Thanks Eddie, Ian -- Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group
Re: [dccp] Re: [PATCH 2/5]: DCCP Recalc on non-loss intervals
On 1/5/07, Eddie Kohler [EMAIL PROTECTED] wrote: The reason for this is if you are recalculating i_mean based on non loss you should check after every packet received. However this involves quite a lot of calculations on linked lists which are CPU intensive and also stall other processes potentially with locks being taken. So what I've done is looked at how many packets of non loss would be required to alter i_mean. This is then added to the current sequence number and stored in hist_recalc_recalcloss. I then just do a simple comparison on every packet to see if we've met this high water mark. I guess there's a minor 4-byte space tradeoff here, but it would seem simpler just to store i_tot0 and i_tot1 as variables in the ccid3 structure. Then on every consecutive non-lost packet you simply increment i_tot1 by 4 and recalculate i_mean. Eddie Don't you still need to iterate through each element of the list then and also do some divisions? This becomes expensive quickly if done for every packet. With my code for example if you are running at 1% loss then you will only recalculate roughly every 100 packets and only then if you haven't had a loss. I would like to change the loss interval linked list to a fixed size 8 element array as we're not changing the size of the linked list at any time so it is very inefficient (probably a text book case of when not to use a linked list!!) Ian -- Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group
Re: [dccp] Re: [PATCH 2/5]: DCCP Recalc on non-loss intervals
On 1/5/07, Eddie Kohler [EMAIL PROTECTED] wrote: You shouldn't need to iterate through the list, since i_mean is just i_tot/w_tot, and w_tot is a constant. You do need to divide, though. If it makes no difference to you I'd recommend going with the simpler version -- the logic in dccp_li_hist_recalc_recalcloss is difficult to follow; I wouldn't want to be on the hook for its correctness ;) I'll have a look at it later on, but don't have much free time at present due to family responsibilities. I've done quite a lot of testing and believe to be correct, and have included a lot of the thinking in the comments. The thing is that it doesn't actually calculate i_mean itself so that same base calculation is used. Also, the weights in dccp_li_hist_w appear to be wrong. They should be 5, 5, 5, 5, 4, 3, 2, 1, not 4,4,4,4,3,2,1,1, according to rfc3448. I don't believe so. We've done this as per section 8 of RFC3448 and divide by 4 rather than 5. -- Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group
Re: [dccp] Questioning TFRC (and TCP) fairness
On 11/5/06, Bob Briscoe [EMAIL PROTECTED] wrote: DCCP folks, I've posted Flow Rate Fairness: Dismantling a Religion draft-briscoe-tsvarea-fair-00.pdf to internet drafts. It explains my strong concerns about the way fairness is thought about in the Internet Community. I show a proper basis for fairness would lead to allocations orders of magnitude different from the ones we currently have. I said this during the standardisation of DCCP, but it needed a much fuller treatment for people to realise why the whole religion is broken. Can you (or someone else) post a URL to this? I'll stop being lazy and try to find it if nobody replies! -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand
Re: [dccp] Packet size s on CCID3 (sudden changes in s)
On 10/5/06, Gorry Fairhurst [EMAIL PROTECTED] wrote: Eddie said: snip No valid implementation would use a large s for X_calc and a small s for t_ipi. They are the same variable and must take the same value in both calculations. (If the app changes s between feedback packets, then maybe the cached X_calc used a different value of s than t_ipi; is this what you're worried about? But that seems like such a corner case, I'd say the implementer can do whatever they want -- either recalculate X_calc or use the old one until the next feedback packet.) Things look clear if packets are of size s. But, as you say, now what happens when your application sends some (many) packets of size s and then increases the size: 160B...160B...160B...1460B...1460B...1460B... It doesn't seem quite right to me, that it can be allowed to send such a step-function in throughput (a large PMTU would reveal a larger problem). Should the sender recalculate t_ipi? (Is it practical?) It should always keep track of t_ipi due to changing loss/rtt. But changing s doesn't alter t_ipi. Or at least, can senders be told to work out that's it has just send n bytes in the period and this will exceed rate X and then stop sending, rather than continue to do this? Gorry If s changes then X changes with it but t_ipi doesn't when you do the maths. Ian -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand
Re: [dccp] DCCP voice quality experiments
I noticed in section IV.A you say no experimental results are available where 0ms delay. I have had problems on Linux also with no delay (well it was 0.26 ms) in that throughput fluctuates significantly. Is this also what you were experiencing? I am wondering whether CCID3 has real problems when delay is very low. In other tests when I have 1.2 msec delay due to added hop the problem goes away. We experienced that with very small delays the behavior of the connection became unpredictable in the way you mentioned, especially when using the small packets variant and allowing a higher send rate. We were not sure if this was a design problem or an implementation problem. I'm not sure of this either. You would think that if we are also getting it on Linux it is a design issue but that is a false assumption since the Linux CCID3 code originated from the WAND CCID3 code which originated from the Lulea code which is on BSD and is probably what the current code is based on. I'll look into it some more as time permits. Ian -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand
Re: [dccp] 8.5. Pseudocode
On 8/8/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello, For study and testing purposes, I am implementing dccp under older version of linux 2.6.10 to run as a module. During basic testing of the protocol I am just wondering why you are doing this when DCCP is in the kernel already? -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand
[dccp] Updated version of iperf for DCCP
Hi there folks, I've put an updated version of the DCCP patch for iperf online at: http://wand.net.nz/~iam4/dccp/dccp-iperf-2.0.2-2.diff Fixes: Works again with later kernels. Thanks Andrea for service code fix Works again with UDP. Thanks Dimitrios for fix Works with UDP if you use --protocol/-X option Help is fixed to display protocol help Can this please be updated on the iperf page? At some stage I think it would be worth merging some of the changes upstream but not entirely sure of the procedure. Can somebody clarify? Thanks, Ian -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand
