Re: [Ekiga-devel-list] 3.2.5 release

[Eugen Dedu <Eugen Dedu pu-pm univ-fcomte fr>]

yannick wrote:
> Damien Sandras a écrit :
> > Le vendredi 10 juillet 2009 à 11:17 +0200, yannick a écrit :
> > > Damien Sandras a écrit :
> > > > Le vendredi 10 juillet 2009 à 10:49 +0200, yannick a écrit :
> > > > > > > > That's what I thought. By default, only a few codecs are enabled.
> > > > > > > The bug is strange, since 
> > > > > > > https://launchpadlibrarian.net/24407094/ekiga_3.2.0-0ubuntu1.diff.gz 
> > > > > > > does not show any change related to enabled codecs in ekiga...
> > > > > > I guess people enable everything.
> > > > > I have done some limited search on the MTU topic and it seems the MTU
> > > > > can vary along the patch. Beside large bandwidth can greatly benefit for
> > > > > a larger MTU than 1500 and some people are pushing to have larger MTU in
> > > > > this case. (I have a report with this case at hand here:
> > > > > https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/380091 )I do not
> > > > > know how the choice if 1500 is made inside OPAL; if it is hardcoded it
> > > > > is probably a source of frame dropping in some case (and it happen
> > > > > probably in silence). Around 1400 seems more safe but it seems to not
> > > > > cover all cases.
> > > > >
> > > > > AFAIK a proper fix for this situation is to use a discovery mechanism
> > > > > for the MTU: fortunately this exist in RFC:
> > > > > http://tools.ietf.org/html/rfc4821
> > > > OPAL does not touch the MTU.
> > > >
> > > > The MTU setting on a machine is an OS thing, not a user program thing.
> > > (ARGH I only answered to Damien, reposting to the list, sorry Damien for
> > > the noise...)
> > >
> > > It does not matter, even if your host has a 1500 MTU, the next hop in
> > > the path can have a 1400 MTU (I agree this should be a rare case), thus
> > > if you only take your host in account you'll be screwed.
> > Anyway, the only clean solution is to use TCP.
>
> By default? If we use UDP by default, then we need either the MTU
> discover mechanism in the RFC, either to use a safer MTU value (1400
> seems a reasonable choice), because AFAIK UDP has no mechanism for
> fragmented packet and frames will be dropped silently if we are in the
> bad range (close to 1500). Or maybe use the fact frame are dropped to
> switch to TCP? Is there a way to know if frames has been dropped?

As I wrote on TCP bug, IPv4 does fragmentation (IPv6 does not).  No need 
to worry about MTU other than the local one.  I can send my courses if 
you wish :o)

--
Eugen