[AG-TECH] VPCscreen, Multicast and TTL

Jason Bell j.bell at cqu.edu.au
Thu Apr 1 10:02:57 CDT 2010

G'day All

Sorry to butt in, but I have just gotten back from holidays (therefore I haven't read this thread properly), but some of these issues described might explain some of the previous problems I have seen personally.  [A VIC site having troubles viewing a Western AUS site's VPC].

Long story short, we had some issues where a user would be connecting via a particular unicast bridge (in Australia) could not see a VPCSCreen session, though, when the AG switched to a different bridge they could see the session.

I initially thought it might be some weird filtering issues, but TTL settings makes more sense.

Some of the issues I saw might collaborate the issue that Philippe is experiencing.

Anyway, I would be happy to hear more about this issue and would be happy to test as well.


-----Original Message-----
From: ag-tech-bounces at lists.mcs.anl.gov [mailto:ag-tech-bounces at lists.mcs.anl.gov] On Behalf Of Christoph Willing
Sent: Friday, 2 April 2010 12:25 AM
To: Philippe d'Anfray
Cc: ag-tech at mcs.anl.gov
Subject: Re: [AG-TECH] VPCscreen, Multicast and TTL

On 01/04/2010, at 11:40 PM, Philippe d'Anfray wrote:

> Bonjour,
> I tried using just vic with a multicast address between "our" two  
> sites.
> It appears that the threshold for the TTL here is... 35 (!)
> (below the video gets lost somewhere)

Good - thats more evidence to support the broken ttl theory.

> If the routers use the policy I read here
> (http://ntrg.cs.tcd.ie/undergrad/4ba2/multicast/antony/)
> ....."The IP multicast routing protocol uses the *Time To Live (TTL)*
> field of IP datagrams to decide how "far" from a sending host a given
> multicast packet should be forwarded.".....
> Then the TTL is used as an "a priori scope"  (and not only as a hop  
> count)
> it is normal that we receive nothing even if the number of hops  
> between
> the two sites here is only 8.

Yes, the general idea is that each router subtracts 1 from the  
incoming multicast packet before sending it onward and when the ttl  
falls to 0, the packet is dropped. So, in theory, packets that start  
with a ttl of 16 would survive 16 hops before being discarded.  
Multicast traffic doesn't always flow the same path as unicast traffic  
between any two sites so counting hops with normal unicast tools is  
only an estimate. Administrators can also impose policy to change  
router behaviour.

Anyway, I think I've found the cause in the vpcscreen code and will  
apply a simple minded fix for testing. Would you be able to test it? I  
can't easily replicate your problem here to confirm that the fix  
works. If you are able to help with the testing, could you confirm  
that you're using Ubuntu 9.10 and whether you're using 32 or 64bit  
version please, so that I can build the appropriate version for you?


> Christoph Willing a écrit :
>>> * With VPCscreen only, all packets corresponding to the video  
>>> stream are
>>> given a TTL of 16
>>> * With VPCscreen and a Video Producer I can see packets with a TTL  
>>> of 16
>>> and others with a TTL of 127
>>> Only those with a TTL of 127 can be received outside the site.
>> Although it is clearly wrong that vpcscreen's ttl is somehow reset to
>> 16 even when you explicitly set it to 127, I would nevertheless  
>> expect
>> that a ttl of 16 is more than sufficient for most multicast sessions
>> within a country - try an ordinary ping to one of your regular
>> destinations - does it take more than 16 hops? So, although there is
>> something wrong with vpcscreen, I think the issue is made worse by
>> some router misconfiguration somewhere in your area (perhaps wrongly
>> passing only multicast traffic with ttl of, say 32).
>> How to fix vpcscreen? I had a quick look through the source code for
>> obvious problems yesterday and found one potential issue but haven't
>> had a chance to investigate it yet - maybe in the next few days.
>> BTW you could confirm that the reduced ttl is actually the cause of
>> your original problem with vpcscreen by running vic (which works as
>> expected with multicast, I think?) with a lower ttl too - does it  
>> then
>> exhibit the same problem of not reaching the destination when you set
>> its ttl to 16?
> <Philippe_d-Anfray.vcf>

Christoph Willing                       +61 7 3365 8316
QCIF Access Grid Manager
University of Queensland

More information about the ag-tech mailing list