Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01

[" Ilpo Järvinen " <[e-mail]>]

On Thu, 14 Apr 2011, Mark Allman wrote:

> 
> > AFAIK you and Ilpo pointed out in your draft that in a case of a
> > segment-based stack the dupthresh counter is not necessary anymore and
> > we can handle everything with IsLost(). So, I recommend that this
> > should be included in 3517bis (as a big side note or in an appendix
> > section)
> 
> We do note in the document ...
> 
>    Finally, note that the algorithm in this document assumes a
>    sender that is not keeping track of segment boundaries after
>    transmitting a segment.  It is possible that a sender that did
>    keep this extra state may be able to use a more refined and
>    precise algorithm than the one presented herein, however, we
>    leave this as future work.
> 
> ... which seems reasonable to me.  The document **does not** seek to
> offer both byte- and packet-based variants.  It is perfectly fine for a
> stack to use a packet-based variant and this document could still form
> the basis of such a beast.  But, such an implementation could likely
> hone a number of things that are approximations in the current document,
> or get by without particular counters or whatnot.  Tracking packets may
> in fact be a good tradeoff in some cases. 

I think there are multiple shades of gray there. 

...In the one end there's fully packet based algorithm and in the other 
fully seqno based one.  The first one is certainly a problem that isn't 
even specified outside of recovery fully afaik, and shouldn't be tried 
here (in 3517bis).  But on the middle ground there's such a version where 
the only the heuristics to detect that dupThresh segments above another 
are SACKed is replaced with an accurate version (it actually doesn't even 
have to be a "packet based" implementation although this information is  
naturally always available in case of packet based implementaion which is 
why it gets mentioned usually as "if TCP is packet based blah blah..."). 

Such refined IsLost just does more accurately what the heuristics 
version of IsLost tried to do. I find it unlikely that there's a can of 
worms in such refining because then the goal of the original heuristics is 
just met more often than in the original. Unless there's something flawed 
in the not-always-met goal of the original heuristics?

-- 
 i.