Re: [Int-area] more feedback on draft-van-beijnum-multi-mtu-02

[Iljitsch van Beijnum <iljitsch at muada.com>]

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
Int-area at ietf.org
https://www.ietf.org/mailman/listinfo/int-area