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

["Anantha Ramaiah (ananth)" <[e-mail]>]

<snip>

> 
> 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.  But, it just
> isn't what this document strives to specify.  Some other document can
> puzzle through a packet-based variant if folks want such a
> specification.

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. 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.

Thanks,
-Anantha