Hello Christian, Thank you again for your review of the draft and comments to further improve it. The updates should appear in the next revision. inline On Sun, Feb 25, 2018 at 11:51 PM, Christopher Morrow <morrowc.lists@xxxxxxxxx> wrote: > > > On Sat, Feb 24, 2018 at 10:29 PM, Christian Huitema <huitema@xxxxxxxxxxx> > 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. Thank you. >> >> 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. Thank you for your thoughts on this section, I hope there will be continued work to determine solutions as you suggest. We'll need to leave solutions as out-of-scope and Mirja had requested in her AD review that we leave out any mention of QUIC, so we need to do that as well. Having said that, how about the following leaving this as future research? An area for further research includes end-to-end solutions that would provide a simpler architecture and may solve the issue with CDN anycast. In this case, connections would be migrated to a CDN unicast address. >> >> 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. > How about the following text Al and I suggest being added to the end of the section: Performance enhancing proxies are primarily used on long delay links (satellite) with access to the TCP header to provide an early ACK and make the long delay link of the path seem shorter. With some specific forms of flow control, TCP can be more efficient than alternatives such as proxies. The editors cannot cite research on this point specific to the performance enhancing proxies described, but agree this area could be explored to determine if flow-control modifications could preserve the end-to-end performance on long delay paths session where the TCP header is exposed. The typos have been corrected in the previous version. Thank you, Kathleen >> >> 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 >> >> >> >> >> >> >> >> > -- Best regards, Kathleen
