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

[Mark Allman <[e-mail]>]

> I have been passively watching this thread. Just wanted to note that
> our implementation(s) uses packet based buffering scheme and it comes
> across handy in many situations including the current case.

I do not doubt that.

> So, I think that adding text that benefits implementations using
> packet variants would be really helpful. Coming back to this thread,
> Between having a separate document that caters to packet based
> variants versus folding the information into the existing document
> itself, I would prefer the latter, FWIW.

Let me stress that RFC3517 (and the bis) do not somehow strive to be
*the* SACK-based recovery algorithm.  It is *a* reasonable way to do
loss recovery with SACK.  We worked very diligently to understand how
this algorithm works (and where it doesn't).  The bis adds a small piece
that makes the scheme more robust.  I think it would be a pity to not
publish that quite soon (and there have been no objections as far as I
can tell to the basic technical merits and/or scheme, but only
refinements to the text to make it more understandable).

Holding the (as best as I can tell) agreed upon bis up so that we can go
back and massage in a variant of the algorithm that leverages
understanding of segment boundaries seems imprudent to me given that (a)
it will take great care (if our experience with RFC3517 is any
indication), (b) we have no idea how hard it will be to get right (we
thought the scheme in RFC3517 would be easy, too, and it took us 2.5
years and 14 revisions) and (c) nobody has signed up to do it.

So, I would *strongly* prefer we push what we agree to out.  And, I
*encourage* anyone who has better ideas to pursue those (e.g., as Matt
and the Google gang are doing).  There needn't be only one.

allman