Hi Eddie, | (1) 's' may be treated in two ways, not three. The specification should be modified to clearly reflect this (as per your reply). | (2) The variability is clearly implementable, just as a TCP stack can | optionally support SACK. With `variability' I referred to `s' meaning one of fixed/average/MSS. | (3) The document offers the implementer a choice. This is entirely typical of | specifications. I don't want to comment on this. | (4) The results published in the literature are evocative, and I agree with | you that packet size is problematic -- whether moving average or MSS. | However, those results do not convince me that CCID 3 with 's=MSS' will be | wildly unfair in practice, relative to (for example) TCP itself with small | packets. For that reason I see no need to deprecate 's=MSS'. Let us gain | implementation experience. I disagree with s=MSS being fair as per previous literature references. As an extreme example: 40byte audio packets over a Gigabit Ethernet card with jumbo frames (MSS=8192). | In addition I feel that, because this area is problematic, other | implementation choices may be justified and useful. Such as packet size | socket options, or virtual packets. I am not going to implement socket options, since this passes the buck from the kernel developer to the application developer. But I take it that this was a hypothetical remark anyway. Loss estimation based on the use of virtual packets is not standardized yet. | > To me LIP Scaling seemed to be the most promising proposal, | | The authors would disagree with you. "Adjusting LIP scaling to byte mode | results is an even less favorable mechanism." ... "Two of the proposed | mechanisms, random sampling and virtual packets, perform well over a wide | range of different network conditions if the network drops packets independent | of their size." ... You are right - I confused one with the other; I did mean `virtual packets'. This also seems easier to implement (not saying I will). | Then set 's=MSS'! As has been mentioned many times before. That is easiest. | And it is clearly based on existing standards-track specifications. Thank you for your comments. As said, I have serious doubts whether using s=MSS is sound, but at least there would then be time to spent on implementation work rather than on research questions. Gerrit
