Some comments below:Abstract - notes ethernets as ubiquitous shared LANs; how about cable internet? Also, ethernets are largely switched except for 802.11
Sec 1.0 - #1 in the list, the header overhead issue seems unimportant; once you're up in 1500B range, the 3-5% overhead doesn't drop enough to matter much to make packets much larger.
#4 in the list (TCP perf) seems derivative of #2. Note that congestion control also becomes potentially more variable, because the granule of response is larger. More on this below...
4821 should be referenced by name (Packetization Layer PMTUD)The second list (end sec 1) seems IPv6-specific, except for IPv4. It would be useful to indicate which items are for which protocol version.
Sec 3.0 - packet loss due to congestion needs to be included as a separate item in the list; note that larger packets makes this worse (fate sharing)
Sec 3.1 - apps care about paths, notlinks. I.e., the issue is the BW of the path, not the link. This begs the overall question of whether this makes fragmentation worse in some cases.
Sec 3.2 - again, this section focuses on what's best for links, not paths. Large packets on a link aren't always good for the path. Also, agreed that the core is fast, but IMO the edge is fairly fast too; it's the access network that is the bottleneck (due to explicit provisioning based on pricing, if not capacity)
The discussion of fate sharing of cost/benefits isn't convincing; there are many parties here (src, router, dst), and the benefits are at all three, where the problems are largely only at the router AFAICT. The fate isn't shared.
Sec 3.4 appears to ignore congestion control losses. I wonder if cong control dominates loss anyway, at which point BER optimization would be noise.
Sec 4.2 - you've focused largely on IPv6 to this point; overall, a comprehensive discussion of both IPv4 and IPv6 would be useful.
Sec 4.5 - the SHOULD appears to apply only to shared links; it seems like that caveat should be included.
I am concerned about having the link layer think it should ever override TCP (w.r.t. MSS, here). This was explored in several BOFs, and overall at best only safe, recoverable optimizations are appropriate. I am not sure whether this is either safe or recoverable (I'm not sure it's not, but that should be discussed).
Sec 4.6 - I am concerned about options that MUST come last; this means this doc overrides all other IPv6 option descriptions. That may impede its deployment and/or acceptance.
Sec 4.7 - again, this option seems like it is appropriate only on shared links; is there a way to limit it to those kinds of links? Does this requirement make IPv6 more fragile / unnecessarily complex in pt-pt links by adding a requirement that isn't needed?
If the packet is lost, it seems like repeating it a few times is a SHOULD. Sec 4.8 - this too seems like it SHOULD be repeated if lost.Sec 4.9 - it's not clear why probing at at least twice the segment size isn't the minimum required; finding the larger MTU is helpful only to the extent that it reduces overhead, packet frequency, etc., and increases smaller than a factor of 2 or so seem moot and not worth over-tuning.
Sec 5 - I am not in favor of transport flags. As per above, I don't think the link should be telling an E2E protocol anything; it's not appropriate.
Sec 6 - replace "serve" with "service". --
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
