On Sat, Feb 24, 2018 at 10:29 PM, Christian Huitema <[email protected]> wrote:
> Kathleen prompted me to review the latest revision of this draft, > promising me that I would "be a lot happier with version 21". I am > actually looking at version 22, and I certainly appreciate the amount of > work that went into improving this draft. We saw 9 revisions over the > last two months, so clearly the authors have been very busy. And the > result is indeed much improved. The old versions were sometimes > irritating, the new version is much easier to follow. I appreciate that > in many places, instead of just lamenting the loss of clear text > inspection capabilities, the draft lists the ongoing efforts in the IETF > to propose alternatives. Mostly, I like the general tone, carefully > asserting that documenting controversial practices is not an > endorsement. And I like the call for cooperation between application > providers and network managers, to develop suitable management and > debugging API. > > By and large, I believe that this document is ready. > > By that, I mean that we have probably reached an equilibrium, and that > further discussions might delay publication, but will not significantly > alter the content. Despite that general assertion of readiness, I think > that mention two sections that could still be improved. > > The section on load balancers (2.2.1) fails to mention that end to end > solutions may very well solve the issue with CDN anycast, by simply > migrating the connections to a CDN unicast address. MTCP would allow > this today, and QUIC most probably will allow that tomorrow. Simple > improvements in the end-to-end transport might obviate the need for > complex deployment of load balancers in the network, resulting in an > overall simpler architecture. > > I am very skeptical of the justification for performance enhancing > proxies in section 2.2.4. It develops the idea that having a form of > These are primarily 'satellite games' proxies.. that early-ack and such to make the long satellite portion of the transport seem short(er). They only REALLY need to see TCP headers, so ipsec is problematic, but not (probably) tls. > hop-by-hop transport would be more efficient than end-to-end transport, > because each hop controller would have a shorter RTT to manage and thus > could react more quickly. I understand that argument, and in fact I used > to believe it in the early 80's. Hop by hop control, as done by X.25 and > HDLC in 1980, was arguably more efficient than end-to-end control via > TCP, although of course less flexible. But then by 1988 Van Jacobson > demonstrated that with improved congestion control, TCP was in fact as > efficient or more than hop by hop alternatives. At that point, the > better flexibility of TCP and the simpler network architecture won the > day. I am pretty sure that someone in the CCRG will come up with > innovative congestion control that will similarly moot the debate. In > fact, they may already have. And I would appreciate a pointer to this > kind of history in the draft. > > I could go on with more detailed feedback, but I want to keep this > review short, and maybe I am suffering a bit from review fatigue. My > final point is that there are quite a few typos in the draft. Please run > a spell checker and fix them. > > -- Christian Huitema > > > > > > > > >
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
