Re: [tcpm] laminar tcp, separate thread

[Matt Mathis <[e-mail]>]

Thanks!   I just realized that my earlier reply wasn't to the entire list.

(Revised)

My big question for Paris will be how to frame this work relative to
TCPM.  I was actually deliberate about writing this draft for the
wrong audience (it is addressed to the WG itself sort of in the form
of an independent submission.  TCPM docs are normally addressed to TCP
implementers.)

It is also very spotty about which algorithms it chose to update.
This will improve as the draft evolves.

I used "undo" in a generic sense.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay



On Wed, Mar 14, 2012 at 3:12 AM, Michael Welzl <[e-mail]> wrote:
> Hi,
>
> I also read Laminar TCP now, and I applaud! This is great stuff!
>
> As for the document itself, while this certainly forms a good basis for
> discussion, if I imagine that being an RFC, I would say that it's too messy,
> in several ways:
>
>
> 1)
> I think that most of what this document does is just to provide guidance to
> application designers, i.e. it could be an informational description of how
> a TCP could be implemented in an easier and more modern fashion. There
> doesn't seem to bee much in it, now, that is (as the abstract says)
> "technically in violation of all existing TCP standards"?   I mean, does
> counting packets instead of bytes make Linux TCP in violation of the
> standards? I guess not... similarly, would I violate standards if I call
> ssthresh "xythresh" in my implementation? I guess not... so I think that
> only behavioral changes really affect the rules laid out by the other TCP
> RFCs.
>
> That would, then, only concern the behavior when TCP is application-limited,
> I think, and that would perhaps only update RFC 2861  :-)
>
> Of course, if that would really lead to an RFC updating not much more than
> RFC 2861 and one or two others, one would have to make pretty damn sure that
> the behavior of Laminar REALLY doesn't diverge from the standards in any
> other way.
>
>
> 2)
> You seem to have made a rather arbitrary selection of algorithms that you
> survey in section 3 - e.g., why mention F-RTO and not Eifel? Anyway both
> really don't seem to have much to do with Laminar...  and which RFC defines
> "Undo"? I guess what you mean is the Eifel Response algorithm.
>
>
> 3)
> I find your mention of aggressiveness, Tragedy of the Commons etc. out of
> place. It just strikes me as unrelated. I also think it's weird to mention
> the de-obfuscation of code achieved with Laminar as a possible security
> concern   :-)
>
>
> Again, all of these comments concern only the document writing style and
> structure, not the technical idea, which I think is just beautiful.
>
>
> Cheers,
> Michael
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm