Re: comments on draft-larsson-v6ops-mip-scenarios-00.txt

[Henrik Levkowetz <henrik@levkowetz.com>]

on 2004-11-19 11:43 am Pekka Savola said the following:
> Hi,
> 
> Sorry for a bit of delay in responding...
> 
> On Tue, 16 Nov 2004, Eva Gustafsson wrote:
>> First, let me say a few words about the scope of the draft. The purpose of 
>> this draft is to provide an overview of (a) possible network and handoff 
>> scenarios; (b) possible deployment cases; and (c) possible solutions. In this 
>> draft, we do not state which deployment cases are the most probable ones - we 
>> just list the possibilities. The intention is to lay out the field, so that 
>> later on, more specific problem statements and solution proposals can be 
>> made, referring to subsets of the scenarios described in this draft.
>>
>> Do you have any comments on this approach?
> 
> So, you're saying this is kind of a "framework" for all the possible 
> scenarios and solutions.
> 
> I'm not sure how sensible that is, because we don't have those 
> specific problem statements/scenario documents.  Further, such a 
> framework document might be a wrong place to have lengthy discussion 
> of solutions.

Well, the thing is, it seems every separate person who makes comments
in this area are looking at only part of the field we have tried to
describe here, and have different requirements, different access
technologies, different trade offs.

I believe it would be very counterproductive to even approach
problem statements in this draft.  Problem statements need to be
focused, and need to lay out the conditions and trade-offs which
exist in each individual case.  But if we don't have a map of the
whole field, it is much more difficult to come together and gain
consensus on a few fairly optimal mechanisms, rather than having
15 different approaches which only works for limited cases.

Whether we are used to playing field description documents like 
this or not, I believe we need the overview which we are trying
to lay out here.  Maybe we need to add text to make it clear what
this document is trying to define, and what it is not touching.

> I certainly sympathize with you that this document should not be place 
> to have length discussions of each scenario and the problem statement 
> behind each scenario -- but what I did prefer to see was around a 
> paragraph or two of text per each scenario, trying to describe it 
> somehow, and state if that's a deployed/planned scenario (and where?), 
> etc. -- just something minor for the readers to get a feel which 
> scenarios are most urgent deployment/planning wise.

Well, to make that complete would take input from ?? hundreds, and
still not be complete - we don't know now what kind of combinations
and deployments we'll see in only a year.  What we _do_ know is how
the combinatorics of the different base technologies works, and this
is a good platform on which to build individual problem descriptions.

I'm thinking that we might complement this document with one other
document, with a problem description which would be of particular
interest to some of us, in order to take another step forward.

>>> Generic comments:
>>> 
>>>   - you raise a number of (potentials) scenarios by enumerating the
>>> possibilities.  I think it would be useful to try to describe, e.g., using 
>>> a
>>> paragraph or two each, the practical use case for each scenario if one
>>> exists, deployments which are planned or exist, etc. -- just as a means for
>>> us to try to identify which are the *MOST* relevant scenarios which must be
>>> addressed.
>>> 
>> See above. More deployment-specific problem statements can be made later, but 
>> that's not really within the scope of this draft.
> 
> I think that diminishes the value of the draft, especially as it tries 
> to analyze the solutions -- which doesn't seem to make sense unless we 
> have some agreement about which scenarios are actually the useful 
> ones?

As indicated above, I think that there are too many possible problem
statements to make it reasonable to even attempt them in this draft.

>>>   - there should probably be some form of problem statement
>>>     why dual MIP protocols is not a good thing.  In each scenario, one 
>>> might
>>>     also consider whether connection survivability is required in that
>>>     scenario.
>>> 
>> See above. In this draft, we do not make statements on whether different 
>> deployment scenarios are good or not - we simply list different 
>> possibilities.
> 
> I wasn't saying "good or not" :)  Just whether it exists today, is 
> seriously planned, etc. -- something to highlight those cases which 
> are more than rows in the matrix for completeness' sake.
> 
> If we can see that there are 2-3 most urgent problems, maybe that 
> might be a factor in figuring out which way we need to start solving 
> these problems.

(Same comments here as above, basically)

>>>   - it probably needs to be evaluated whether it's assumed that particular
>>> type of access technology (and the resulting tunneling method) must be
>>> usable everywhere, or just in particular operator's (or operators')
>>> networks.  I.e., "where can the user roam, and still expect this to work?"
>>> Different solutions have different assumptions on this..
>>> 
>> Ok... I'm not sure I fully understand what you mean by "type of access 
>> technology". Could you please elaborate on this?
> 
> Sorry, I meant like, IPv4 (private), IPv4 (public), IPv6.
> 
> For each of these also when the service is available no matter where 
> you're located in the Internet, or whether just when you are in a 
> particular access network (e.g., inside a particular operator's 
> network).  (This is probably a very important distinction, because 
> these are fundamentally very different service models.)
> 
>>> semi-substantial
>>> ----------------
>>> 
>>>     The issue of handoff latency would be especially important in cases
>>>     where Mobile IP provides mobility for real-time applications, e.g.
>>>     Voice over IP calls.  In these cases, an absolute minimum of
>>>     signaling roundtrips is required at each handoff.  Also, when running
>>>     real-time applications, a mobile node cannot afford to await timeouts
>>>     in deciding which mobility signaling mechanism to use when arriving
>>>     at a new access network.
>>> 
>>> ==> it's worth mentioning the unstated assumption here is that wireless
>>> links being considered here have very long roundtrips (e.g., 0.2-1.0
>>> seconds) that it is actually *this* what causes the problems, not as such
>>> the number of roundtrips..
>>> 
>> Sure, the latency depends on the length of the roundtrip as well as the 
>> number of roundtrips. We have not made any assumption on the length of the 
>> roundtrips for wireless links though.
> 
> Right.. but I think the fundamental assumption is not that the 
> signalling roundtrips are too costly (too many bits sent), but rather 
> because signalling with many roundtrips just takes way too much time 
> (due to the access technology), thus the need to minimize the number 
> of roundtrips.

Basically true, but the roundtrip may vary between few ms to few seconds,
depending on access technology, and depending on the application that
may matter greatly or not too much at all.

>>>     o  A solution for deployment case III (MIPv4-MIPv6) needs to handle
>>>        network scenarios 1-2, 7-8 in Table 1 and 9-10 in Table 2.  The
>>>        handoff scenarios listed in Tables 3 and 4 are not really
>>>        applicable to this type of solution.  As the aim is to address
>>>        MIPv4-MIPv6 interworking, we may assume that MIPv4 and MIPv6 run
>>>        in parallel on the MN and the HA, and that the MN will be able to
>>>        shift MIP version during a handoff, accommodating to the IP
>>>        version of its current access network.  For this to work, the MIP
>>>        stack in the MN also needs to provide the appropriate MIP
>>>        transport for both IPv4 and IPv6 sockets.
>>> 
>>> ==> "run in parallel" -- does that mean that only one version is used at a
>>> time (as a means of transitioning from X to Y -- some UEs might implement
>>> both, but just one both), or that both are used?
>>> 
>> As MIPv4 does not run over IPv6, and MIPv6 does not run over IPv4, the 
>> assumption is that the MN runs MIPv4 when in an IPv4 network and MIPv6 when 
>> in an IPv6 network.
> 
> OK.  An in a dual-stack network...?
> 
> Maybe the problem statement for deployment case III, then, is that 
> it's OK to have to implement both MIP protocols on the hosts and HAs, 
> but it's not OK to have to perform dual signalling either on v4-only, 
> dual-stack or v6-only network?

Again, this depends on your deployment scenario :-)  Describe one, and
we have the start of a problem statement building on the playing field
we have attempted to describe :-)

>>>     A solution of this kind consists of two parts:
>>>     1.  Enhance MIPv4 to provide support for tunneling MIPv4 packets over
>>>         IPv6 transports.  This solves scenario 5 in addition to 1, and
>>>         scenario 6 if combined with the enhancement below.
>>>     2.  Enhance MIPv4 to carry IPv6 payloads.  This solves scenario 2,
>>>         and scenario 6 if combined with the enhancement above.
>>> 
>>> [...]
>>> 
>>>     A solution of this kind consists of two parts:
>>>     1.  Enhance MIPv6 to provide support for tunneling MIPv6 packets over
>>>         IPv4 transports.  This solves scenario 4 in addition to 8, and
>>>         scenario 3 if combined with the enhancement below.
>>>     2.  Enhance MIPv6 to carry IPv4 payloads.  This solves scenario 7,
>>>         and scenario 3 if combined with the enhancement above.
>>> 
>>> ==> I think you should also discuss how you assign v6 or v4 addresses
>>> (respectively) on top of that link ?  I.e., how address assignment is done?
>>> 
>> We did not consider address assignment within the scope of this draft. The 
>> only issue I can think of would be the case of an MIPv4 FA. We could 
>> elaborate on that. Was that what you had in mind?
> 
> It may not be in scope of the draft as such, but it is certainly in 
> scope of the solutions you're discussing in the draft.  MIPv4 or MIPv6 
> extensions (at least under certain scenarios) seem to require an 
> address assignment mechanism, which has not been addressed in the 
> solutions, and hence is a short-coming in the solutions.

No, this I don't see.  There is one address assignment which we have
(consistently, I believe) not covered, which is getting a local address,
and this should be the same cost for all solutions.  In the Mip 4/6 
cases the Home address is already assigned and fixed, no need to 
do that on the fly - well, it's even (mostly) a silly idea in the
context of mobile ip [although there are provisions for dynamic address
assignment within at least MIP4 - don't know about MIP6 and I'm not
sure it's even a good idea to go there :-)]

> For example, if you have a dual-stack node in a v6-only network and 
> using MIPv6, and you want to run v4-only apps on that node, you'll 
> need somehow to assign the v4 address on the node.  Using transition 
> mechanisms provides you an address; using MIPv6 would require that 
> MIPv6 extension would also include a DHCP-like mechanism for the hosts 
> to obtain a v4 address.  The same applies to MIPv4 for v6 addresses.

In this case you want MIP6 to carry both your IP4 and IP6 traffic,
so you need a Home Address for both. But this would not (normally)
be dynamically assigned, that would loose you a lot of the inherent
benefits of MIP.   Yes, sure, the assignment of a MIP4 home address
has to be described in a solutions draft, but I don't see it belonging
here as it doesn't affect the handover dynamics.

>>>     In general, transition mechanisms solve the issue of transporting,
>>>     e.g.  MIPv6 over an IPv4 network (public or private).  Mechanisms in
>>>     the host for allowing the Mobility protocol to transport multiple IP
>>>     protocol versions, rather than only the native IP protocol version,
>>>     need to be addressed through extensions to the Mobility protocol.
>>> 
>>> ==> is the latter sentence substantiated?
>>> 
>> As far as we understand, this would be the most straighforward way 
>> of solving it. Do you have a suggestion of alternative ways?
> 
> One could, for example, add a tunnel to the stable home address; this 
> would cause additional encapsulation.  Not sure if that would be OK, 
> but at least it's an option.
> 
> For example, when in v4-only environment and using MIPv4, one could 
> build a v4-in-v6 tunnel (if FA is co-located) to the v4 home address, 
> also addressing the IPv6 address stability problems without any need 
> for signalling etc.

I think you mean a v6-in-v4 tunnel here, and that is one way of doing
it.  It would give more transport overhead, of course, and as MIP is
already basically a traffic tunnelling proposition, it makes not a lot
of sense to me personally ,:-)  But yes, this could be done - now we
have to wonder if it is sensible enough that we should increase our
matrices with another dimension and include this in the draft :-)


	Henrik