Re: [MMUSIC] Comments on draft-singh-avtcore-mprtp-04

[Varun Singh <[e-mail]>]

Hi Tiru,

Clarifications inline.

On Fri, Mar 23, 2012 at 13:35, Tirumaleswar Reddy (tireddy)
<[e-mail]> wrote:
>
>>
>> Hi Tiru,
>>
>> Response inline.
>>
>> On Wed, Mar 21, 2012 at 20:07, Tirumaleswar Reddy (tireddy)
>> <[e-mail]> wrote:
>> > Hi Varun -
>> >
>> > I have few comments related to the draft
>> >
>> > a)How is the situation handled when new network paths become
>> > available/disabled after the call is setup ?
>> >
>> >     (3G enabled/disabled after the call is setup)
>> >
>>
>> This is a local decision and MPRTP will use all available paths.
>> Either the application or ICE or something else needs to tell MPRTP
>> when an interface is available or unavailable.
>>
>> At the media level (in the worst case) the sending endpoint will
>> discover a path is unavailable when a subflow reports 100% loss and it
>> will stop using it. Alternatively, if the endpoint discovers that one
>> of its interface is disabled it can advertise a new set of interfaces
>> (excluding the disabled interface from the set) to the other endpoint.
>
> Please refer RFC 6419 on the problems and behavior of various OS related to MIF. For example Section 3.1.2 Connection Manager only selects the best possible connection for the app based on the destination. The default connection manager always prefers wired over wireless.
>

You are right that the connection manager chooses the interface but
this is probably true for any protocol that tries to do multipath. The
application probably needs to either override this behavior (e.g.,
sudo/ raw sockets/ kernel configuration) or the scheduling algorithm
needs to make sure that it does not cause congestion by assuming
multipath and sending too much data.

>>
>> > b)There is little information related to IPv6. How SIP Client would
>> pick
>> > among list of ULA, link-local addresses, IPv6 global addresses with
>> > different precedence using ICE (refer to
>> > draft-keranen-mmusic-ice-adress-selection) ?
>> >
>>
>> It is also a local decision. This should not be different from the
>> choices made by an endpoint using a single path. if an endpoint is
>> using ICE then it just inherits the ICE priorities.
>
> For example consider a IPv6 Mobile Node making SIP call in PMIPv6. This node could be assigned both MAG and LMA prefixes. Let's say the destination is reachable through both the prefixes. But the issue is only LMA prefix would offer mobility if Mobile Node moves out of the hotspot MAG prefix will not be available. In a different region he may get a different MAG prefix. But if we consider a branch with multiple ISP - such complexities may not arise. The problem in this case would be the SIP client being provided the list of host candidate addresses with the preference provided by RFC 3484 (and using ICE). You will need support from OS to achieve this.
>

Yes, support from the OS or some rules (described in the
aforementioned RFC/drafts) are needed to restrict the list of
interface candidates. We will make this clear in the upcoming drafts.

Cheers,
Varun


-- 
http://www.netlab.tkk.fi/~varun/