Subject: [Mipshop] [New Draft] Link Characteristic Information for Mobile IP

From: Soohong Daniel Park <[email-masked]>
Date: Thu, 14 Apr 2005 08:37:08 +0900

Not sure which working group would be fit for this proposal, so
I am posting it to multiple mailing list (MIP4,MIP6 and MIPSHOP)

All comments are highly welcome.

======================================================
A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Link Characteristic Information for Mobile IP
	Author(s)	: S. Park, M. Lee
	Filename	: draft-daniel-mip-link-characteristic-00.txt
	Pages		: 8
	Date		: 2005-4-13
	
This document introduces a new model for link characteristic
information that is sent by the mobile node to let the correspondent
node know which link is being used for communication between them.
This utility allows the correspondent node to forward its ongoing
traffics within the bandwidth of the mobile node while the mobile
node changes its link.  This model can be applicable for Mobile IPv4
as well as Mobile IPv6.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-daniel-mip-link-characteristic-00.
txt

Regards.
---------------------------------------------
Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics.
ENCODING mime
FILE /internet-drafts/draft-daniel-mip-link-characteristic-00.txt
_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Greg Daley <[email-masked]>
Date: Thu, 14 Apr 2005 15:06:27 +1000

Hi Daniel,

It's nice to see such a succinct draft describing an interesting
concept.

How dow you see the MN being able to indicate its expected throughput on
particular multiple access of bandwidth varying links?

Is this in scope?

It reminds me of a simplified version of ABR from ATM, providing
feedback information to the far end to limit congestion within the
network (which isn't necessarily a bad thing here).

It would be good to see if there are some performance figures you could
show regarding packet drop rates on intervening Routers and APs, both
with and without this information.

Perhaps these could go to IRTF mobopts to stimulate discussion?

Greg

Soohong Daniel Park wrote:
> ------------------------------------------------------------------------
> 
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
> 
> 
> ------------------------------------------------------------------------
>

---

From: "Ji Zhang" <[email-masked]>
Date: Thu, 14 Apr 2005 10:32:59 +0100

Hi Daniel,

Please see inline another question in addition to Greg's...

> particular multiple access of bandwidth varying links?

When the MN is communicating with multiple CNs, is it sending the same
bandwidth information to all CNs? If yes, traffics from all the CNs could
overflow the bottleneck link; if no, how would you manage to assign
bandwidth for each CN?

> Is this in scope?

Ji

---

From: Soohong Daniel Park <[email-masked]>
Date: Fri, 15 Apr 2005 11:01:05 +0900

Greg, see my comments inline.

> particular multiple access of bandwidth varying links?

Originally, I thought of this aspect would be out of scope
of this document since it may be an implementation manner.
I think link info of DNA can be used for this aspect. 

> network (which isn't necessarily a bad thing here).

same concept of mine over the wireless environment.

> Perhaps these could go to IRTF mobopts to stimulate discussion?

Well, evaluation effots would be a good reference of course, but
I'd like to discuss this conceptual model on standard aspect.

Thanks.

---

From: Soohong Daniel Park <[email-masked]>
Date: Fri, 15 Apr 2005 11:07:08 +0900

Hi Ji.

> bandwidth for each CN ?

When attaching a new link, MN sends its current
bandwidth (depending on link type) to CN. It means
all CNs will receive the same bandwidth from MN.

Thanks.

---

From: "Junghoon Jee" <[email-masked]>
Date: Fri, 15 Apr 2005 11:47:26 +0900

Hi Daniel,
It's an interesting approach.
Bundling the current interface link status with the location update function
can make many interesting application.

One question about this.
Could you tell me why do you apply this feature only between the MN and CN ?
I guess that it may be helpful between the MN and HA in the situation where
the RR is not supported in MIP4/MIP6.

Typo about your draft even though it's very minor. :-)
The 5th paragraph in the section 4, 

"In vertical handover, the mobile node can be moved to various links
such as wireless pan area, wireless lan ***are->area*** and cellular area
and
each link has its own specific ***cnaracteristic->characteristic***
information."

Regards,
Junghoon 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Soohong Daniel Park
> Sent: Friday, April 15, 2005 11:07 AM
> To: 'Ji Zhang'; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Mipshop] [New Draft] Link Characteristic 
> Information for MobileIP
> 
> 
> Hi Ji.
> 
> > bandwidth information to all CNs? If yes, traffics from all the CNs 
> > could overflow the bottleneck link; if no, how would you manage to 
> > assign bandwidth for each CN ?
> 
> When attaching a new link, MN sends its current bandwidth 
> (depending on link type) to CN. It means all CNs will receive 
> the same bandwidth from MN.
> 
> Thanks.
>

---

From: Greg Daley <[email-masked]>
Date: Fri, 15 Apr 2005 12:52:23 +1000

Hi Daniel.

> I think link info of DNA can be used for this aspect. 

Certainly, it makes sense to me.

> I'd like to discuss this conceptual model on standard aspect.

That's fair enough.

We've been fairly successful in stimulating discussion in Mobopts
though, and have some hopes that some of the work from there may
progress into standardization in the nearer future.

I'm not aiming at deflecting the work, but it has been useful for
other technologies to gain a foothold without worrying about
deferral due to the existing workload of a WG.

Just an idea to consider.

Greg

---

From: Soohong Daniel Park <[email-masked]>
Date: Fri, 15 Apr 2005 13:38:27 +0900

Hi Junghoon, see my comments inline.

> the RR is not supported in MIP4/MIP6.

I don't have any restriction in this document.
I will consider what you say.

> each link has its own specific ***cnaracteristic->characteristic***

done.

Thanks.

---

From: Soohong Daniel Park <[email-masked]>
Date: Fri, 15 Apr 2005 13:40:09 +0900

Hi Greg,

> deferral due to the existing workload of a WG.

I make sense. 

Thanks your idea...:-)

---

From: "Ji Zhang" <[email-masked]>
Date: Fri, 15 Apr 2005 12:17:49 +0100

Hi Daniel,

> all CNs will receive the same bandwidth from MN.

Then I am not convinced this model would work in the case of multiple CNs.

On the other hand, even when there is only one CN, the performance of this
model could be debatable IMHO, unless the link characteristic information
can be delivered to the CN before the actual handover. Otherwise it could be
too late for the CN to be aware of the limited bandwidth of the MN's new
link, in which case the new link's downlink buffer could already overflow,
and upper layer flow/congestion control will take effect anyway.

These are just my concerns...

Ji

---

From: Soohong Daniel Park <[email-masked]>
Date: Fri, 15 Apr 2005 21:30:36 +0900

> These are just my concerns...

In the case of vertical handover, your concern
may not be able to be guranteed. It means some 
packet losses are not avoidable during handover.
(Industrial development can be used for reducing
packet loss, but it's an product manner IMHO)
I did focus on how CN can recognize MN's changed 
link bandwidth after attaching a new link since
current scheme did not consider this aspect. 

Am I missing anything ?

If a redundant time is available for myself, I will try 
to implement this mechanism into my lab as soon
as possible...

Thannks

---

From: "Jee J.Z." <[email-masked]>
Date: Fri, 15 Apr 2005 14:02:10 +0100

Hi Daniel again,

> current scheme did not consider this aspect. 

OK. If you don't consider the predictive manner, I think an Active Queuing Management (AQM) scheme, such as RED, at the new link's buffer would be enough to achieve similar goal, even in the case of multiple CNs. Of course, your approach bears its own advantages, one of which could be that redundant packets do not need to be sent over the Internet to the bottleneck link.

> to implement this mechanism into my lab as soon

I am looking forward to...

Ji

---

From: "Junghoon Jee" <[email-masked]>
Date: Wed, 20 Apr 2005 19:25:53 +0900

Hello Ji.
My comments inline. 

> [mailto:[email-masked]] On Behalf Of Jee J.Z.
> Sent: Friday, April 15, 2005 10:02 PM
> To: Soohong Daniel Park
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Mipshop] [New Draft] Link Characteristic 
> Information for MobileIP
> 
> Hi Daniel again,
> 
> >> > > bandwidth information to all CNs? If yes, traffics 
> from all the 
> >> > > CNs could overflow the bottleneck link; if no, how would you 
> >> > > manage
> >> to assign
> >> > > bandwidth for each CN ?
> >> >
> >> > (depending on link type) to CN. It means all CNs will 
> receive the 
> >> > same bandwidth from MN.
> >> 
> >> Then I am not convinced this model would work in the case 
> of multiple 
> >> CNs.
> >> 
> >> On the other hand, even when there is only one CN, the 
> performance of 
> >> this model could be debatable IMHO, unless the link characteristic 
> >> information can be delivered to the CN before the actual handover.
> >> Otherwise it could be
> >> too late for the CN to be aware of the limited bandwidth 
> of the MN's 
> >> new link, in which case the new link's downlink buffer 
> could already 
> >> overflow, and upper layer flow/congestion control will take effect 
> >> anyway.
> >> 
> > In the case of vertical handover, your concern may not be 
> able to be 
> > guranteed. It means some packet losses are not avoidable during 
> > handover.
> > (Industrial development can be used for reducing packet 
> loss, but it's 
> > an product manner IMHO) I did focus on how CN can recognize MN's 
> > changed link bandwidth after attaching a new link since 
> current scheme 
> OK. If you don't consider the predictive manner, I think an 
> Active Queuing Management (AQM) scheme, such as RED, at the 
> new link's buffer would be enough to achieve similar goal, 

Ji,
Where is this queuing scheme adopted ? in the AR ?
I think that the proposed scheme has a benefit of informing the CN of the
current link status of MN.
I don't think this scheme is comparable to any higher layer's congestion
control mechanism.
I think its example application as the situation where the actual data
source of the CN is changed by finding out the current MN's link status.
Anyway, this is so application specific discussion.
IMO, the bundling the link characteristic information with BU is nice way to
inform the current link status to the counter part. 
Do we have another way to do this ?
I guess that use of any application specific signaling is possible according
to each application.
But I think supporting this in the layer 3 might be an effective way.

Daniel,
Do you assume the link change is the same as IP handover ?
As I know, the link change in the IEEE term is L2 link change.
But, in IETF the link change means the L3 change.
So, I guess that the L2 link change might not cause the L3 handover ?
What do you think about this ?

--Junghoon

> even in the case of multiple CNs. Of course, your approach 
> bears its own advantages, one of which could be that 
> redundant packets do not need to be sent over the Internet to 
> the bottleneck link.
> 
> > Am I missing anything ?
> > 
> > If a redundant time is available for myself, I will try to 
> implement 
> > this mechanism into my lab as soon as possible...
>

---

From: "Ji Zhang" <[email-masked]>
Date: Wed, 20 Apr 2005 18:45:59 +0100

Hi Junghoon,

Please see inline...

> Where is this queuing scheme adopted ? in the AR ?

It should be located at the bottleneck buffer, where excess queuing or buffer overflow may occur.
Of course, it is better if IP layer information is accessible in the queue (e.g. in the AR), since in this
case ECN can also be adopted without dropping TCP packets.

> But I think supporting this in the layer 3 might be an effective way.

I agree and I support the draft, but I am just arguing two points:
1. Working in a predictive mode may bring better performance on handovers. 

2. The scheme must be designed to work when there are multiple nodes (including CNs, HA, PAR, etc.) 
    communicating with the MN. If we send the same bandwidth information to multiple nodes, the total traffics
    sent by these nodes could overwhelm the MN's access link. 

Without considering these two points, it is not clear to me whether it is worth the effort rather than simply using an AQM.
The second point is what I am concerned most. I've proposed some text to Daniel, but still don't know what he thinks.

> What do you think about this ?

Sorry to interrupt: Even the L2 link does not change, its capacity could change. So IMHO the MN could choose the timings
to send BUs with link characteristics, not necessarily on L3 handovers.

Ji

---

From: Greg Daley <[email-masked]>
Date: Thu, 21 Apr 2005 10:31:02 +1000

Hi Ji,

It seems that there's an essential difference in focus between
the draft as proposed, and efforts to improve handling of congestion
in the network.

The draft itself looks like a basic technique to allow for congestion
avoidance at traffic sources.

Changes to infrastrucutre are not explicitly required, and the
adoption of non MIPv6 (MN, CN, HA) based techniques such as AQM
is surely orthogonal to the proposal.

The effectiveness of the technique itself is yet to be tried,
and may require further investigation.

Ji Zhang wrote:
[chop]
> It should be located at the bottleneck buffer, where excess queuing
 > or buffer overflow may occur. Of course, it is better if IP layer
 > information is accessible in the queue (e.g. in the AR), since in this

The assumption implicit in the draft is that the bottleneck buffers
are in the first and final hops: The wireless links.

The knowledge that a host is on a particular constrained link technology
can help to identify the "narrowest pipe" for throughput (or even
expected link transit delays???).  The draft itself doesn't provide
state information for the current utilization, estimated link
transit delay or other relevant parameters.   Such information may
be useful, but also may take too much time to gather for MIPv6 RO
which is essentially aimed at being a (rapid???) path repair
mechanism.

The knowledge is based on the idea that the MN itself knows about
the locally adjacent link (through DNA or whatever), and can pass
this knowledge to the other side.

These things may be useful, but are potentially problematic to gather
and interpret.   Further investigation may be required into what's
readily available.... I don't know myself....

If the wireless link itself (or the parameters provided) are not
sufficient to identify the bottleneck, the data may still be useful,
if it is more constrained than other information recently passed to
the CN about the path to the MN.

This should have an effect by starting to reduce the CN's throughput
before congestion is reached in the network on the bottleneck link.
(i.e. at least it won't exacerbate congestion, if the path hints
are used to reduce flows rapidly and only increase them slowly).

> 1. Working in a predictive mode may bring better performance on handovers. 

Except you've never been on the new link, so you may not be aware of
local performance constraints... (worth investigating if this is
useful).

> 2. The scheme must be designed to work when there are multiple nodes
 >    (including CNs, HA, PAR, etc.)  communicating with the MN. If we
 >    send the same bandwidth information to multiple nodes, the total
 >    traffic sent by these nodes could overwhelm the MN's access link.

Absolutely.

I agree that this is one of the critical issues: what is currently
available on the visited link (in terms of bandwidth and utilization),
as well as what should be expected when all of the MN's sessions arrive.

There may be 'rules of thumb' (estimations) which the MN can
tell the peer CNs which don't harm the network they arrive upon.

> Without considering these two points, it is not clear to me whether
 > it is worth the effort rather than simply using an AQM.  The second
 > point is what I am concerned most. I've proposed some text to Daniel,
 > but still don't know what he thinks.

Please remember that this solution is Infrastructureless, and carried
on between a remote device (CN: not in control of visited network
mechanisms) and a visiting local device (MN: not in control of the
visited infrastructure).

Surely infrastructure techniques can assist, and will be able to
do so in some circumstances.   Their universal deployment is another
thing.

A dumb Internet which still provides good performance, since
the end nodes are clever is cheap to deploy and easy to maintain.

So while there may still be work needed on this idea, the
direction is promising.

Perhaps we should take this discussion to [email-masked]?

Greg

---

From: "Junghoon Jee" <[email-masked]>
Date: Thu, 21 Apr 2005 09:43:21 +0900

Hi Greg,
 
I agree with your comment but,
I don't know the clear reason why we have to move this discussion to the
Mobopts.
So many, almost every items to the Mobopts ? :-)

I think the key idea of this approach is to bundle the L2 information to the
L3 location update.
I guess it can be a topic of DNA, MIP4, MIP6 and MIPSHOP.
What do you think ?

Regards,
Junghoon

> From: Greg Daley [mailto:[email-masked]] 
> Sent: Thursday, April 21, 2005 9:31 AM
> To: Ji Zhang
> Cc: Junghoon Jee; [email-masked]; [email-masked]
> It seems that there's an essential difference in focus 
> between the draft as proposed, and efforts to improve 
> handling of congestion in the network.
> 
> The draft itself looks like a basic technique to allow for 
> congestion avoidance at traffic sources.
> 
> Changes to infrastrucutre are not explicitly required, and 
> the adoption of non MIPv6 (MN, CN, HA) based techniques such 
> as AQM is surely orthogonal to the proposal.
> 
>  > or buffer overflow may occur. Of course, it is better if 
> IP layer  > information is accessible in the queue (e.g. in 
> the AR), since in this
> The assumption implicit in the draft is that the bottleneck 
> buffers are in the first and final hops: The wireless links.
> 
> The knowledge that a host is on a particular constrained link 
> technology can help to identify the "narrowest pipe" for 
> throughput (or even expected link transit delays???).  The 
> draft itself doesn't provide state information for the 
> current utilization, estimated link
> be useful, but also may take too much time to gather for 
> MIPv6 RO which is essentially aimed at being a (rapid???) 
> path repair mechanism.
> 
> The knowledge is based on the idea that the MN itself knows 
> about the locally adjacent link (through DNA or whatever), 
> and can pass this knowledge to the other side.
> 
> If the wireless link itself (or the parameters provided) are 
> not sufficient to identify the bottleneck, the data may still 
> be useful, if it is more constrained than other information 
> recently passed to the CN about the path to the MN.
> 
> This should have an effect by starting to reduce the CN's 
> throughput before congestion is reached in the network on the 
> bottleneck link.
> (i.e. at least it won't exacerbate congestion, if the path 
> hints are used to reduce flows rapidly and only increase them slowly).
> 
> >>I think that the proposed scheme has a benefit of informing 
> the CN of 
> >>the current link status of MN.
> >>I don't think this scheme is comparable to any higher layer's 
> >>congestion control mechanism.
> >>IMO, the bundling the link characteristic information with 
> BU is nice 
> >>way to inform the current link status to the counter part.
> >>I guess that use of any application specific signaling is possible 
> >>according to each application.
> Except you've never been on the new link, so you may not be 
> aware of local performance constraints... (worth 
> investigating if this is useful).
> 
> I agree that this is one of the critical issues: what is 
> currently available on the visited link (in terms of 
> bandwidth and utilization), as well as what should be 
> expected when all of the MN's sessions arrive.
> 
>  > it is worth the effort rather than simply using an AQM.  
> The second  > point is what I am concerned most. I've 
> proposed some text to Daniel,  > but still don't know what he thinks.
> 
> Please remember that this solution is Infrastructureless, and 
> carried on between a remote device (CN: not in control of 
> visited network
> mechanisms) and a visiting local device (MN: not in control 
> of the visited infrastructure).
>

---

From: Greg Daley <[email-masked]>
Date: Thu, 21 Apr 2005 14:33:03 +1000

Hi JungHoon,

I'm a firm believer that a solution standardized too
soon, can lead to a longer development time.

Please see below how I think Mobopts can help.

> So many, almost every items to the Mobopts ? :-)

Exactly.

If there's uncertainty of the applicability, or further work
required to prove the validity of an idea, IMHO it should
go to mobopts.

This allows good ideas to grow to maturity without having to
compete with other immature ideas to get adopted by the working
group immediately.

> I guess it can be a topic of DNA, MIP4, MIP6 and MIPSHOP.

Certainly the idea is a good one, but the raised questions:

1. What does actually gain for end-hosts ?
2. Does it provide all the information needed
	(bandwidth, utilization, etc.)?
3. Does it have the potential to damage existing traffic?

...may need to be looked at in more detail.

While the idea is good, we need to see that this is the best
information to provide, and that it is useful and ready to
pursue from a standardization, rather than a research perspective.

DNA, MIP4, MIP6 and MIPSHOP are aimed at producing standards.
While the idea may be good, it may need work to be 'good enough'.
If all 'good' ideas were added as options to a protocol, there'd
be confusion as to which good ideas to implement or support.

Mobopts is a good place to test these things.
I submit work to mobopts too.

Best Regards,

Greg

---

From: "Ji Zhang" <[email-masked]>
Date: Thu, 21 Apr 2005 15:01:36 +0100

Hi Greg,

I understand your points, but again, I am suggesting some text to improve
the draft,
not arguing against the draft. I mentioned about AQM just in order to give
an example
to support the two points I suggested that the draft needs improving. The
text I
suggested to Daniel to the draft (maybe in section 4) was something like:

\start
In the case that the mobile node is communicating with multiple nodes, the
mobile node and each communicating node SHOULD exchange Binding Update and
Binding Acknowledgement messages with the link characteristic information
option. The total bandwidth specified in all link characteristic information
options SHOULD not exceed the maximum bandwidth available to the mobile node
on the current access link. However, the bandwidth assignment algorithm for
each communicating node is out of the scope of this document.

To avoid a possible situation that a link capacity may already be
overwhelmed before the link characteristic information arrives at a
communicating node after a handover, this model is most valuable if
handovers can be performed in a predictive manner. Therefore, this model is
recommended to be applied together with a fast handover protocol (for
example, FMIPv6 and Mobile IPv4 LLH) in its predictive mode.
\end

I mentioned the predictive mode because I have simulation results on
handover performance
between two links with very different characteristics, which show that
without prediction and
therefore without performing flow control beforehand, a slow link could
easily be overwhelmed
by incoming traffics right after a handover. However, prediction is never
mandatory, and that's
why I only say "recommended" in my text.

What do you think?

Ji

> >>I guess that use of any application specific signaling is possible
according

---

From: Ranjitsinh Wable <[email-masked]>
Date: Thu, 21 Apr 2005 20:32:37 +0530

Hi Ji,

I have two points here

1) We can not convey Link information in only BU message as it may not be 
the change of CoA when you change the link.
    So we need separate message to convey the link information when we 
change only L2 not L3.

2) I agree your point that the predictive information of the link 
characterstic will always help to avoid the situation that a link capacity 
may already be overwhelmed before the link characteristic information 
arrives at a communicating node after a handover.

But in the predictive updation of the link characterstics to the 
corresponding CNs I think we have to deal with the following  problem

In predictive Model when the link information will be exactly conveyed to 
CNs??

    e.g. shall it be coveyed while sending the FBU? or after receiving the 
BAck.

    If the predictive handover if MN chooses the multiple points of 
attachement and may be want to decide the any L2                 association 
based on the signal strength of available links when the existing signal 
strength goes below the some threshold         value. Whether we will inform 
the complete set of link informations to the all the CNs?

    MN in FMIPv6 never send BU to the CNs when it is in the previous link. 
Bcoz he does not want to convey the CoA             until it gets finalized.

Let me know your opinion on this.

Regards,
Wable

----- Original Message ----- 
From: "Ji Zhang" <[email-masked]>
To: "Gregory Daley" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Soohong Daniel Park" 
<[email-masked]>
Sent: Thursday, April 21, 2005 7:31 PM
Subject: Re: [Mipshop] [New Draft] Link Characteristic Information for 
MobileIP

---

From: "Ji Zhang" <[email-masked]>
Date: Thu, 21 Apr 2005 18:27:44 +0100

Hi Ranjitsinh,

Please see inline...

>     So we need separate message to convey the link information when we

I don't think a separate message other than BU is needed. IMHO, a MN can
choose its timing to send BUs with link information when it senses the
access link capacity changes, not necessarily on any L3 or L2 handovers.

> In predictive Model when the link information will be exactly conveyed to

I suppose it may be first conveyed by the FBU to the PAR before the MN sends
any BUs to its HA and CNs. CNs may be informed by the normal BUs. However,
flow control to PAR may in turn affect the CNs' throughput earlier than the
normal BUs do.

> the complete set of link informations to the all the CNs?

I think this is out of the scope of the draft.

> Bcoz he does not want to convey the CoA             until it gets
finalized.

Traffics from PAR may also need controlling, not necessarily CNs.

Ji

> >> The knowledge that a host is on a particular constrained link
technology

---

From: Ranjitsinh Wable <[email-masked]>
Date: Mon, 25 Apr 2005 12:28:15 +0530

Hi Ji,

Here are my comments inline...

----- Original Message ----- 
From: "Ji Zhang" <[email-masked]>
To: "Ranjitsinh Wable" <[email-masked]>
Cc: "Gregory Daley" <[email-masked]>; <[email-masked]>; 
"Soohong Daniel Park" <[email-masked]>; <[email-masked]>
Sent: Thursday, April 21, 2005 10:57 PM
Subject: Re: [Mipshop] [New Draft] Link Characteristic Information for 
MobileIP

> access link capacity changes, not necessarily on any L3 or L2 handovers.

So we need to send the BU whenever the link capacity change happens (???)
May be fine to do that as it also covers the binding update info that will 
require
while sending the link capacity change.

> I think this is out of the scope of the draft.

It may be out of the scope of the document but we need to consider this 
factor when
we want to decide the procedure.

> Traffics from PAR may also need controlling, not necessarily CNs.

Controlling the traffic from the PAR to the MN is understood but again how 
much
we are going to get benefited out of it? IMHO to achieve the link 
characterstic update
in predictable manner we are adding burden on the PAR and controlling the 
traffic whereas
the CN will keep on  sending the traffic with same rate unless link capacity 
is updated
to him.

> Ji
- Regards

Wable

---

From: "Ji Zhang" <[email-masked]>
Date: Mon, 25 Apr 2005 12:10:23 +0100

Hi Ranjitsinh,

Please see comments inline...

> So we need to send the BU whenever the link capacity change happens (???)

I think this is implementation dependent. I agree that BU should not be sent
too frequently. Specific algorithms may be able to reduce the BU sending
rate by giving some tolerance to link capacity changes.

> we want to decide the procedure.

OK. I suppose the CN does not support multiple mobility bindings, so the CN
may only know one care-of address of the MN. Therefore, if these attached
links offer different care-of addresses, the MN should choose one for the CN
by sending a BU including that link's capacity (assigned to the CN) info. If
the MN is attaching different links with the same care-of address (if this
is possible in reality), the MN could sum these links' capacity when
composing BUs.

> the CN will keep on  sending the traffic with same rate unless link
capacity

The CN will keep sending traffics with the same rate to the PAR anyway no
matter whether or not FMIP is deployed. Therefore if the PAR is going to
redirect packets to the new link, flow control should be needed. IMHO this
is not a big burden since the PAR may just need to drop packets
occasionally. Dropping packets may in turn affect the CN's upper layer
sending rate (e.g. TCP), thus the CN's traffics may already be reduced when
it gets a BU.

Ji

---

From: Soohong Daniel Park <[email-masked]>
Date: Mon, 25 Apr 2005 20:27:46 +0900

> local performance constraints... (worth investigating if this is

Agreed, the predictive mode would be a good alternative with this
draft, but I am still not convincing how MN can recognize its 
predictive link information...So it still remains out of scope
in my understanding.

---

From: "Ji Zhang" <[email-masked]>
Date: Mon, 25 Apr 2005 12:41:21 +0100

Hi all,

> predictive link information...So it still remains out of scope

Maybe the Candidate Access Router Discovery (CARD) protocol can help. Access
router capabilities exchange from nAR to MN is supported there.

Ji

---

From: Soohong Daniel Park <[email-masked]>
Date: Mon, 25 Apr 2005 20:42:53 +0900

> So we need to send the BU whenever the link capacity change 

I don't think MN will send lots of BU. Rather than *whenever the
link capacity change*, I'd say *whenever MN attaches a new
link*...

---

From: Ranjitsinh Wable <[email-masked]>
Date: Mon, 25 Apr 2005 18:02:28 +0530

> link capacity change*, I'd say *whenever MN attaches a new
Its fine to send the BU on new link attachment or even in the link
capacity change. I was just wondering that whether we need to
send BU in case of w/ and w/o L3 change. But its OK as we need
Binding Info when we send the link update.

--Wable

---

From: "James Kempf" <[email-masked]>
Date: Mon, 25 Apr 2005 09:15:13 -0700

CARD has recently been published as an Experimental RFC, RFC 4066.

            jak

----- Original Message ----- 
From: "Ji Zhang" <[email-masked]>
To: "Soohong Daniel Park" <[email-masked]>; "Gregory Daley"
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, April 25, 2005 4:41 AM
Subject: Re: [Mipshop] [New Draft] Link Characteristic Information for
MobileIP

---

From: Greg Daley <[email-masked]>
Date: Tue, 26 Apr 2005 09:28:26 +1000

Hi Ji,

Ji Zhang wrote:
[chop]
> rate by giving some tolerance to link capacity changes.

I guess that the host will be aware of changes through local knowledge
upon arrival at a new network.  It's reasonable to leave this up to the
MN if a BU is not otherwise going to the CN.

[chop]
> is possible in reality), the MN could sum these links' capacity when

It would choose the capacity of the link to which it is attached and
wants to receive data at.

Where it has multiple interfaces on the same link, this will be the
interface whose MAC address is given to the routers for Neighbour
Discovery.

It won't be the sum of the interfaces, since the Neighbour Cache only
maps to one MAC, and link-layers don't understand one MAC's presence
at two points.

[chop]
> sending rate (e.g. TCP), thus the CN's traffics may already be reduced when

Lets not worry too much about the PAR.

This is an end-to-end optimization (to the CN), which can work with
HAs and PARs, but it's not necessary to complicate things by worrying
about them now.

Greg

---

From: Greg Daley <[email-masked]>
Date: Tue, 26 Apr 2005 10:38:13 +1000

Hi Daniel,

> link capacity change*, I'd say *whenever MN attaches a new

I think that if the path between the MN and CN changes, the
binding update may have to be sent in some circumstances.

This may be the case even if the path only changes within the last hop
network to the MN, and theres' no change in CoA.

Greg

---

From: Soohong Daniel Park <[email-masked]>
Date: Tue, 26 Apr 2005 10:51:28 +0900

Are you saying CARD is so useful to support
the predictive manner in this draft ?

More detailed something would be more
appreciate to me if feasible...:-)

Thanks. 

> [mailto:[email-masked]] On Behalf Of James Kempf
> Sent: Tuesday, April 26, 2005 1:15 AM
> To: Ji Zhang; Soohong Daniel Park; Gregory Daley
> Cc: [email-masked]; [email-masked]
> > Maybe the Candidate Access Router Discovery (CARD) protocol 
> can help.
> Access

---

From: "Ji Zhang" <[email-masked]>
Date: Tue, 26 Apr 2005 11:56:09 +0100

Hi Greg,

> wants to receive data at.

Right, that is what I suppose to say.

> maps to one MAC, and link-layers don't understand one MAC's presence

OK. Thanks for pointing this out.

> HAs and PARs, but it's not necessary to complicate things by worrying

Alright. Just because people bring the issue up.

Thanks,
Ji

---

From: "Ji Zhang" <[email-masked]>
Date: Tue, 26 Apr 2005 12:18:24 +0100

Hi Daniel,

A short and incomplete description to CARD:

The CARD protocol is originally designed to enable seamless IP-layer
handoff. Its main function is assisting a MN to discover the identities (IP
addresses) of the possible handoff target Access Routers (candidate ARs),
and choose the one whose capabilities is the best match to the preferences
of the MN to perform a handoff. CARD supports both IPv4 and IPv6.

More specifically, CARD accomplishes reverse address translation and
discovery of candidate ARs' (CARs) capabilities. The CARD Request and the
CARD Reply messages are defined for these purposes. Prior to an IP-level
handoff, a MN may gather the layer-2 (L2) IDs of potential handoff target
access points. Triggered by a specified L2 event, the MN sends a CARD
Request to its current AR containing the obtained L2 IDs to initiate the
CARD process. Optionally, the MN also includes its preferences on
capabilities of interest in the CARD Request message. On receipt of the CARD
Request, if the current AR maintains sufficient information about the
requested L2 IDs and its neighbouring ARs' capabilities, a CARD Reply is
generated to the MN accordingly, specifying the IP addresses mapping with
the requested L2 IDs and relevant ARs' capability parameters; otherwise, it
composes another CARD Request message to a third party (either its
neighbouring ARs or a CARD server) to query, and after it gets the CARD
Reply from the third party, a CARD Reply to the original CARD Request
initiated by the MN is returned.

The capability parameters are not defined in CARD, so it could be possible
to carry some link characteristic info of the nAR.. In this way, the MN
could be able to get the new link's information before it actually attaches
to it.

Ji

---

From: "James Kempf" <[email-masked]>
Date: Tue, 26 Apr 2005 08:27:47 -0700

I was just providing a reference to the draft, which is now published.

In general, CARD can be used to advertise characteristics of the link, like
available bandwidth, as an aid to making handover decisions.

With regard to the specific proposal, I have not read the draft, but I share
Gab's opinion about this being more a transport item.

            jak

----- Original Message ----- 
From: "Soohong Daniel Park" <[email-masked]>
To: "'James Kempf'" <[email-masked]>; "'Ji Zhang'"
<[email-masked]>; "'Gregory Daley'" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, April 25, 2005 6:51 PM
Subject: RE: [Mipshop] [New Draft] Link Characteristic Information for
MobileIP