Re: [PATCH 5/5]: Revert use of MSS instead of s

[Gerrit Renker <gerrit@erg.abdn.ac.uk>]

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.