Re: [dccp] Packet size s on CCID3

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

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