Quoting Ian McDonald: | > | It really depends on whether existing TFRC is meant to be phased out and | > | replaced or whether the application can choose - like a lot of TCP | > | enhancements e.g. SACK. I think 3448bis should be the default but whether | > | the only option is another question... | > I disagree with the idea. It is already the case that the many documents (3448, 4340, | > 4342, rfc3448bis, Faster Restart draft) all make related, but in a subtle way different | > interpretations of the same thing. I recall that when I did the patches, I would spend | > reading up to two or three hours the different drafts, because they are all not really | > consistent. What you are proposing is a parallel implementation of both the orthodox | > RFC 4342/3448 if I understand you correctly. With that you only increase the number of | > nightmares, since now you need not only align drafts, but also track sub-changes of | > different drafts in the code. | > | OK. Herein lies my problem. For my research I want to see what | improvements Faster Restart make to performance of my tests. However | as you point out it is quite complicated. I absolutely don't think we | should be tracking differences between 3448 (original) and 4342 - it | is clear 4342 takes precedence. If we implement drafts we need to | update with any changes but we don't need to keep past history there - | only latest version of draft. For me personally I need to track Faster | Restart. Where it's becoming an issue for me though is that there is | overlap between FR and 3448bis. It's causing me a bit of grief to be | honest. Can understand that - that is partly why I suggested to wait a little, and see if and the two drafts stabilise. If there were updates to 4342 then I would also be all for tracking them. However, 4342 is written in such a clever way that updates of 3448 do not apply. I am in support of the 3448 draft changes that are in the kernel so far, since to my understanding they improve the performance over an `orthodox' 4342; the point being that no one cares how orthodox the implementation is when the performance is awful. | I believe 3448bis changes should be brought into code without having option to | enable/disable - much like Reno in the kernel is really NewReno. Yes, agree fully with that point. Am not fully sure about the status of 3448bis, during the past 5 months there have been heavy, frequent and also retracted changes. | I think Faster Restart should be an option though much like SACK, ABC, FRTO are in the | kernel. Makes sense. I thought your concept of using a socket option was a good one, since it could be reused later for CCID4 (it is not a single-CCID socket option). | > Already the code is not really orthodox RFC 4342, we have for instance the | > Request/Response RTT sample which is not part of the document, and there are several | > other features (can list them if > needed) | If you do have a list of them it would be great. I see quite a few | comments about bis in the code. I don't have a list at present, need to go through the works. Will post at a later point. | > We could fork subtrees for such features, how about this? That would keep defaults | > and new features separate, at least for a while, and they can be integrated when the | > specification gains maturity. | > | I'm against forking trees if at all possible as it makes tracking | changes a nightmare. However if my patches are purely experimental, | and won't ever make it into mainline (e.g. my send best packet next) | I'll keep them as a separate patch series which can be a separate | branch if needed/wanted. Forking trees is actually not so bad with regard to tracking the changes. I am doing that frequently for the test tree when the netdev tree changes. If there are not too many subtrees, (more than a handful), I'd say that this is feasible. It also makes it easier to track what is going on, and can be used as a temporary workspace while patch sets are under discussion. - 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
