3.2.5 release

[Yannick-GNU/Linux]

Eugen Dedu a écrit :

> 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)
>

Good to know. Thank you. Well, for my education if you could send me
your courses in private i'll be happy ;)
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Eugen Dedu]

yannick wrote:

> Eugen Dedu a écrit :
>> 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)
>>
>
> Good to know. Thank you. Well, for my education if you could send me
> your courses in private i'll be happy ;)

In French, "Technologie IP", http://eugen.dedu.free.fr/index.html#teaching

--
Eugen
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Yannick-GNU/Linux]

Eugen Dedu a écrit :

> yannick wrote:
>> Eugen Dedu a écrit :
>>> 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)
>>>
>>
>> Good to know. Thank you. Well, for my education if you could send me
>> your courses in private i'll be happy ;)
>
> In French, "Technologie IP", http://eugen.dedu.free.fr/index.html#teaching
>

I digged this up further. To really be sure Ekiga handle all that
properly, I've 2 questions:

* there is flag to allow, or not, fragmentation. Does Ekiga use this flag?
* in some cases, an ICMP packet can be send back if the datagram turn to
be too big for some operations. How ekiga deals with this?
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list