Attention is currently required from: laforge.

pespin has posted comments on this change by pespin. ( https://gerrit.osmocom.org/c/osmo-ggsn/+/38500?usp=email )

Change subject: doc: Document MTU features in User Manual and example config files ......................................................................

Patch Set 5:

(2 comments)

File doc/manuals/chapters/running.adoc:

https://gerrit.osmocom.org/c/osmo-ggsn/+/38500/comment/408c74a5_346c33c0?usp... : PS5, Line 57: When running osmo-ggsn, the user must take network Maximum Transmission Unit : (MTU) into consideration, and configure it based on network specific setup.

I think this is too strong a statement. There's nothing inherently wrong with IP fragmentation. […]

Indeed there's nothing wrong with IP fragmentation. The problem is, as usual, broken middleboxes. It may indeed not be a problem under most mobile network setups since the whole network is controlled by the same operator (and even so it may be problematic).

But given that some users are actually running over satellite links, this becomes more of a problem. We already have seen some production users having problems where all the traffic becomes stalled due to some middlebox silently dropping big SCTP chunks.

So it's not really *only* optimization, despite in most cases it will be so. I agree though I can rephrase the sentence to be less drastic.

https://gerrit.osmocom.org/c/osmo-ggsn/+/38500/comment/e064720f_ba58a806?usp... : PS5, Line 122: OsmOGGSN

• spelling (OsmO vs Osmo) […]

Sure, but it is still interesting to document imho since: * Being stream-based, TCP will attempt to fill as much as possible the packets up to the MTU. * Probably >95% of the traffic from users will be TCP.

Good point about increasing the outter MTU, I'll document that somewhere in there or another section. This again only works if the operator controls all the related network.