Subject: Re: [MMUSIC] ICE reducing number of checks (was Re: ICE pacing connectivity checks)

From: Benny Prijono <[email-masked]>
Date: Thu, 26 Apr 2007 11:42:28 -0400

also inline.

> See inline.
> -- Philip
> On 25-Apr-07, at 22:16 , Benny Prijono wrote:
>
>> Philip Matthews wrote:
>>>> (please see this table with fixed width font)
>>>>
>>>>          Agent A               |         Agent B
>>>>  candidate=1.1.1.1 1 typ host  | candidate 1: 3.3.3.3 3 typ host
>>>>  candidate=2.2.2.2 2 typ host  | candidate 2: 4.4.4.4 4 typ host
>>>>
>>>> With usual ICE, these checks will be created on agent A:
>>>>
>>>>   #1)  1.1.1.1:1 --> 3.3.3.3:3
>>>>   #2)  1.1.1.1:1 --> 4.4.4.4:4
>>>>   #3)  2.2.2.2:2 --> 3.3.3.3:3
>>>>   #4)  2.2.2.2:2 --> 4.4.4.4:4
>>>>
>>>> Now, if agent A uses a single socket for all host candidates,
>>>> AFAIK check #3 will produce the same result as check #1, and
>>>> check #4 will produce the same result as check #2.
>>> This is where I disagree. In my opinion, check #1 and check #3 are
>>> not the same (and nor are checks #2 and #4).
>>> Let me illustrate by elaborating more on my previous example.
>>> On Agent A,
>>>    - say the interface with address 1.1.1.1 is a 802.11 interface
>>> that connects to an access point which then connects via ethernet
>>> to a router that connects to the Internet; and
>>>    - say the interface with address 2.2.2.2 is an ethernet
>>> interface that connects to the same router.
>>> Say static/default routing is used throughout. So if someone
>>> unplugs the ethernet cable leading to the wireless access point,
>>> the box on which Agent A runs will not see any routing updates or
>>> similar. However, packets sent out the wireless interface will
>>> just be dropped (hopefully with an ICMP Destination Unreachable
>>> reply, but even that is not certain).
>>> In this case, check #1 and #2 will fail, but check #3 and check #4
>>> will succeed.
>>
>> Let me come back to this after I explain more about my approach
>> below, since there seem to be a misunderstanding.
>>
>>
>>> However, your comment does point that you have to force the
>>> packets out the correct interface.
>>
>> No, that is exactly what you MUST NOT do when using my approach!
>>
>> Using my approach, socket MUST ALWAYS be bound to INADDR_ANY
>> (0.0.0.0), to allow the OS to choose the appropriate interface when
>> sending the request.
>>
>> There seems to be a misunderstanding. When I said that the agent
>> perform this connectivity check (using my approach):
>>
>>    1.1.1.1:1 --> 3.3.3.3:3
>>
>> It doesn't mean that the agent must somehow force the socket to
>> send from interface 1.1.1.1:1. No, that's not what I meant.
>>
>> What I meant is that the agent should choose local host candidate
>> 1.1.1.1:1 as the local candidate of the check. But as I said, it
>> doesn't really matter which local candidate to use as the local
>> part of the check, since all candidates shares the same socket.
>>
>> The socket itself is still bound to INADDR_ANY, to allow the OS to
>> choose which interface to send the packet from. We don't need to
>> care what interface is chosen for the packet. If the connectivity
>> is successful the peer will tell us what it is in XOR-MAPPED-
>> ADDRESS attribute in the response.
>>
>> I hope I'm making myself clear.
>>
>> Now back to the examples.
>>
>>
>> Case 1:
>> =============
>>
>>
>> Suppose an agent has these connectivity checks as the result of
>> pairing process with normal ICE:
>>
>>   #1)  1.1.1.1:1 --> 3.3.3.3:3
>>   #2)  1.1.1.1:1 --> 4.4.4.4:4
>>   #3)  2.2.2.2:2 --> 3.3.3.3:3
>>   #4)  2.2.2.2:2 --> 4.4.4.4:4
>>
>> And it has this routing table:
>>
>>   1.1.1.0/24  use interface 1.1.1.1
>>   2.2.2.0/24  use interface 2.2.2.2
>>   0.0.0.0/0 (default) use interface 2.2.2.2
>>
>> Now even if interface 1.1.1.1 is up, check #1 and #2 will always
>> fail (immediately with ENETUNREACH/EHOSTUNREACH error, at least on
>> Windows and Linux) if you use standard ICE, so the question is why
>> bother creating these checks in the first place?
>>
>> With my approach, these checks will be created instead:
>>
>>   #1)  0.0.0.0:0 --> 3.3.3.3:3
>>   #2)  0.0.0.0:0 --> 4.4.4.4:4
>>
>> (I put 0.0.0.0:0 as the local part to make it clearer that the
>> application does not specify which interface to use).
>>
>> With this approach, the OS will choose for us which interface to
>> use for sending the request, and in this case it will choose
>> interface 2.2.2.2.
>>
>> So both approaches yield the same result.
>
> Let's change your example to have the default route point out
> interface 1.1.1.1 rather than interface 2.2.2.2 (this could easily
> happen, after all). Then let's merge this with my example where
> 1.1.1.1 is a 802.11 interface which leads to an Access Point whose
> cable in unplugged (so packets are dropped at the Access Point rather
> than being forwarded),  while 2.2.2.2 is an Ethernet interface and
> has proper Internet connectivity.
>
> Under these conditions, your approach will always send out interface
> 1.1.1.1 (in effect, only doing checks #1 and #2), and both of these
> checks will fail. However, assuming other things are OK, a working
> path could be found using interface 2.2.2.2, but your implementation
> will never find this path.

You're assuming that just because you bind() your socket to a specific
interface, you can force the OS to spit packets out of that interface,
bypassing the routing table. It won't work. The OS will return
ENETUNREACH/EHOSTUNREACH error if you try to do this.

So you can't send packet to 3.3.3.3 or 4.4.4.4 using interface 2.2.2.2, if
the default route points to interface 1.1.1.1. Your connectivity checks
will always fail.

And so are mine, in this case, because 1.1.1.1 is down.

So both approaches produce the same result, again.

  -benny

> Remember that, in my example, the OS on which Agent A is running is
> only using static routing, so it doesn't have any way to discover
> that packets sent out interface 1.1.1.1 get dropped before they reach
> the Internet.
>
> Does this help?
>
> - Philip
>
>

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic