Thanks for the comments, Joe. I'll address most of them in a new version of the draft.
On 11 mrt 2008, at 15:46, Joe Touch wrote: > 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. Right, 3% or 2% overhead isn't really an issue. However, at 1500 bytes with IPv6 and the TCP timestamp you only get 1448 payload bytes out of your 1500 byte MTU and ethernet adds 18 bytes + the equivalent of 20 bytes for the preamble and inter-frame gap so you're using 1538 bytes on the wire, so you're only 94.1% efficient and if you add a TCP ack for every 2 data segments it's even worse at 90.9%. > Sec 3.1 - apps care about paths, notlinks. I.e., the issue is the BW > of the path, not the link. Right, but we don't know the bandwidth of hops in the middle, only the bandwidth at the two endpoints. This is why it's important that administrators can set a maximum packet size. > Sec 4.5 - the SHOULD appears to apply only to shared links; It doesn't. > 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). You told me that BSD probably already overrules the MSS options on sessions on the local subnet. If that's true, the draft is actually more conservative than current practice. Because per-neighbor MTUs aren't known when a session is first set up, it's not possible to advertise an appropriate 1500+ MSS. Having to stick with 1500 bytes when the correspondent says it can handle something much larger seems rather suboptimal, so I assume that implementers will want to work around that. By having this bit, a host can explicitly tell another host what its wishes are in this regard, so there is no chance that bad things happen unintentionally. So if you don't want to overrule the MSS, set the bit to 0 on send and ignore it on reception, send only packets that fit in the MSS and there's no danger that others will be sending you larger packets. > 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. This is a consequence of the breaking of the 8 byte alignment in case we want to pad to something that isn't 8 byte aligned. If we agree that we don't want to do that this restriction is unnecessary. > Sec 4.7 - again, this option seems like it is appropriate only on > shared links; The opposite. On a shared link you know that packets of a certain size make it through or not so no need to probe. Probing discovers switches with limited MTU sizes. > If the packet is lost, it seems like repeating it a few times is a > SHOULD. Both sides will initiate this so two packets must be lost before a retransmission is really needed. It doesn't seem worth the complexity to do those retransmissions just to cover the case where two packets are lost. The mechanism will also restart after an idle period when entries were garbage collected from the neighbor cache. > Sec 4.9 - it's not clear why probing at at least twice the segment > size isn't the minimum required; Even a 1508 byte MTU can be useful: this gives you a 1500 byte MTU after applying PPP over ethernet. _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
