Re: [Int-area] draft-learmonth-intarea-rfc1226-bis-00

["Iain R. Learmonth" <[e-mail]>]

Hi,

On 23/05/2020 18:24, Joseph Touch wrote:
> For this protocol, all you really care about is EMTU_S (as defined in
> RFC1122 - see draft-ietf-intarea-tunnels, which admittedly needs to be
> refreshed in ample spare time).
> 
> For IPv6, this is 1500; for IPv4 it is 576. Those are more than
> sufficient if you aren’t significantly affected by packet loss per se,
> which *can* be amplified by source fragmentation, but that might not be
> relevant in this case.

Right.

> If you want to talk about performance under certain losses where
> fragmentation causes a known problem, you should add an additional
> suggestion to do path MTU discovery (PLPMTUD - which you SHOULD really
> build in if it isn’t there yet), because otherwise you’re stuck with the
> path mins of 1280 for IPv6 and (sorry, still) 64 for IPv4.

Negotiation of frame size in AX.25 only occurs in certain conditions,
and unlike for IP transport protocols, the path parameters will
generally be co-ordinated, agreed and known ahead of time. AX.25 is not
used for internetworking and this draft is closer to "Ethernet-over-IP"
than it is to "IP-over-IP" in that respect.

In the event that fragmentation is required, and the link is expected to
have higher levels of loss, I would just recommend against use of this
encapsulation rather than attempting PLPMTUD.

> Although I agree all new drafts need to address IPv6, it’s naive to
> ignore IPv4 - especially for a protocol such as this, which is, if
> anything, more likely to operate using legacy equipment.

Agreed.

Thanks,
Iain.

-- 
https://hambsd.org/