Subject: [Mipshop] comments on draft-ietf-mipshop-transient-bce

From: <[email-masked]>
Date: Sat, 18 Apr 2009 20:50:52 +0200

Hi Marco and I-D co-authors,

I've reviewed transient binding draft. The first comment is that the
document is well written and looks good; however I have few minor
comments and clarifying questions: 
 
In the abstract:

You wrote:
"transient binding cache entry which is used for inter-MAG handover
optimization" 
The term "inter-MAG handover" is not appropriate in the context covered
by this document, so I'd propose to rewrite as:
" transient binding cache entry which is used for inter-access handover
optimization", or  " transient binding cache entry which is used for
inter-technology handover optimization"

In section 1 you wrote: 

- "The transient BCE extension, as specified in this document, avoids
such [packet] loss for MNs,...". It is a strong claim; I mean if
timeouts used by the solution are not perfectly tune some packets could
be lost. So I'd propose to rewrite as: "The transient BCE extension, as
specified in this document, increase handover performance (packet loss
and transmission delay) experienced by MNs,...". 

- "A transient binding on the LMA can be controlled remotely, such as
from a MAG, or by local information, such as events." What do you mean
by controlled by local information / event? Can you elaborate?

Section 2.2 terminology: 

- definition of inter-RAT handover should be removed because only Figure
1 refers to "inter-RAT". Moreover definition of interface (just before
definition of inter-RAT) refers to wireless and wired accesses; so it
suggests that handover considered in this document is not limited to
handover between radio access. 

Section 3.1: handover using a single interface:

- text states: "During an intra-technology handover, some of the MN's
uplink traffic may still be in transit through the pMAG." . 
I do not get where the residual uplink traffic comes from in that case.
Let me explain may concern: I think the section refer to single radio
case right? If yes, the MN is attached to only one MAG at a time and we
cannot argue on the difference of delays between access links, as
explained in section 3.2.2. (the MN is still using the same technology).
So, I do not see why uplink traffic are in transit.

Section 3.2.1:

- you wrote "If the MAG's buffer overflows or the MN cannot reply to
address resolution signaling for too long, data packets for the MN are
dropped and the MN can experience severe packet losses during an
inter-technology handover...". 
I agree but this statement is also true for handover between two
interfaces of the same technology; so I'd be more generic by replacing
"inter-technology" with "inter-access".

- s/Figure 1: Issue with inter-RAT mobility./ Figure 1: Issue with
inter-access mobility./ . The rationale for this modification is that
the call flow, depicted on figure 1, is not limited to handover between
radio accesses. 

Section 4.3, 4.5.1, 4.8:

- editorial comment: s/takes the decision/makes the decision/

- clarifying question regarding fig 4: I think there is a need to
clarify why uplink can be routed via nMAG in transient-L state. Because,
AFAIU, late path switch is expected to maintain routing via pMAG until
connectivity to nMAG is completed; so basically the uplink traffic
cannot be routed via nMAG in transient-L state because the MN has no IP
connectivity with nMAG. So, I guess that "nMAG [Ul]" within transient-L
box in figure 4 is valid only if connectivity with nMAG has been
completed and TIMEOUT_1 not expired. Is that correct? 

Section 4.4:

General comment on MAG operation: in the document, it is assumed that
nMAG controls the handover, but how MAG can decide to use, or not, late
path switch? How MAG can decide to go in A state? Actually I don't think
the MAG has all information to make such a decision. Because, typically,
nMAG should know about previous link characteristics to decide if
transient-A could help. Moreover, ideally, nMAG should tune timeout_2
according previous link characteristic for a better handover
performance. But only the LMA knows both previous and new access link,
so only the LMA is able to make the decision to request correct
transient state. In other words, the LMA should be the entity
controlling the transient-A state and, to avoid complex decision
mechanism, MAGs should be configured to perform late path switch by
default. What do you think? 

Section 4.5.1:

- it is said that "In case the LMA finds the L-flag as well as the
A-flag of the received Transient Binding option set to 0, but the
lifetime field of the Transient Binding option is set to 0,...". 
I think the text is not consistent: L-flag and lifetime set to 0 is an
error case because, referring to section 5.1:
 "In case the L-Flag of the Transient Binding option is set to 1, the
Lifetime field MUST be set to a non-zero value. Lifetime field MUST be
set to a non-zero value."

Section 4.8: protocol stability: 

- what happen when MN looses connection with pMAG while the
corresponding BCE is still in a transient state L or LA? Actually, I've
in mind the following: issue could be a handover failure for a MN moving
out of the pMAG's coverage if TIMEOUT_1 is too long.  

Annex A.1:

This section states:

"Since the downlink data path between the LMA and the nMAG is not setup
at the same time of the uplink data path setup, the LMA must continue to
forward downlink data packets to the pMAG.  Additionally, this system
utilizes a layer 2 forwarding mechanism which enables the delivery of
the downlink data packets to the mobile node location while being
attached to the nMAG."

Here you assume the MN maintains IP connectivity with both pMAG (for
downlink) and nMAG (for uplink). However, from my understanding, a
single radio terminal can setup a IP stack on only one interface at a
time. So, the use case you describe in this section does not seem to be
a real single radio use-case. Are you thinking about a specific
technology? Can you clarify the use-case? 
 
Best regards,
Pierrick

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 20 Apr 2009 12:24:52 +0200

Hi Pierrick,

thanks a lot for your comments. Please see feedback inline.

[email-masked] schrieb:
> document is well written and looks good;
thanks.

>  however I have few minor
We wrote this to cover the optimization of both, dual-radio as
well as the single radio handover in case there is access specific
forwarding in the radio access below MAGs. We thought a detailed
decription in the abstract this is too much, so we kept it short. But I
am ok with rewriting this based on one of your proposals.

> and transmission delay) experienced by MNs,...". 
The timeout is just a delimiter, hence a max lifetime of the transient BCE.
There is no need to fine tune this, it simply must provide a mean to 
terminate
the transient BCE without signaling. Normally, we expect the MAG to
terminate the tBCE with signaling. The only reason where I still see some
packets lost is a too short lifetime. Too long timeout does not matter, as
the nMAG terminates the transient state after the new link is available.
But I am ok with adopting text according to your proposal.

> by controlled by local information / event? Can you elaborate?
"Local event" could be a timeout. But it could also be an event that's
triggered by some other entity, such as for radio control. This entity
could terminate a transient BCE after it ensured that the radio bearer
set up has been completed and is available for data traffic (just as
example). Maybe a good idea to include one or two examples as note?

> 1 refers to "inter-RAT".
Ok.

>  Moreover definition of interface (just before
The target use cases focus on radio access, this is true. Conceptually, 
it could
also be used for wired access. If you think this is confusing, we could 
remove
the 'wired' part.

> So, I do not see why uplink traffic are in transit.
Optimization for single radio is not that generic as for dual radio handover
and focuses on accesses, which support forwarding between handover
source and target radio access networks 'below' the MAGs (active handover).
Hence, a mobile can be attached to the new MAG while it still receives 
traffic
through the pMAG (as it's forwarded from previous access to the new
access). Same for uplink, some packets may still be forwarded reversely
through the pMAG. That's why transient BCE forwards uplink packets
from both MAGs, the pMAG and the nMAG. Such use case is described
in A1. Do you think we should descibe this use case more in detail, e.g.
show the radio access forwarding between previous and target access?

> "inter-technology" with "inter-access".
Ok, thanks.

> the call flow, depicted on figure 1, is not limited to handover between
True. Thanks.

> - editorial comment: s/takes the decision/makes the decision/
Ok, will correct this.

> completed and TIMEOUT_1 not expired. Is that correct? 
We had detailed use cases at this place, but moved them to
the appendix (A.1 and A.2) according to feedback we received. From them,
it should be clearer. But as they are now in the back of the doc, I agree
with you that we should add a clarifying note in section 4. Thanks.

> default. What do you think? 
If it's useful or not to include an A state depends on the source and
the target radio access. Handover from a 'slow' 3G link to a 'fast'
WLAN connection can benefit from A state, as delayed/slow uplink
packets from pMAG may arrive at the LMA after the MN's handover
(Fig. 2). At least nMAG should know about the type of handover,
as this is needed to set the mandatory HI option flags. If the nMAG
does not know about the HO source technology, setting the A-flag
does not hurt. But there are some single radio HO cases where going
through A simply does not make sense. I also agree with your comment
that the LMA should be allowed to set the transient states. This case is
included in the specification. Do you think we need to highlight this
case (LMA controlled transient BCE) more?

And if I get your comment right, you also propose the nMAG sets the
L-flag but to allow the LMA to 'add' setting the A-flag? That's ok from
my point of view and can easlity be added. Thanks!

> set to a non-zero value."

Correct, the MAG MUST set a lifetime field not non-zero in
case L==1. But in the LMA description, you must specify how the
LMA behaves in case a MAG does not follow this rule. In both cases,
(L==1 and timeout==0) and for (L==0 and A==0), the LMA ignores
the Transient Binding option and performs according to RFC5213. Please
correct me if I overlooked something.

> out of the pMAG's coverage if TIMEOUT_1 is too long.  
Important for us is that in such case the performance is not worse than
with RFC5213 and the protocol operation is stable. In your case, the
MN looses packets. Timeouts delimit the lifetime of the transient state
and normal states will recover after expiration. I think your case implies
that the MN attaches to the nMAG: In that case the nMAG will
terminate the transient binding as soon as the new connection has been
set up completely. Performance will be in any improve compared to RFC5213.
A too long TIMEOUT_1 does not matter in case nMAG terminates the transient
state according to the specification. But I think your example is worth 
being included
to section 4.8. Thanks.

> technology? Can you clarify the use-case? 
Yes, this is a 3GPP single radio handover use case. The access
system (below MAGs) forwards downlink packets from previous base station
to the new base station, hence the LMA must forward downlink packets
to the pMAG (and to the previous base station accordingly). Uplink packets
can be routed through the nMAG earlier, as this direction is set up
before the downlink path. Do you think we should include an associated 3GPP
reference? For this specification, we decided to keep it more general and
for the single radio HO we just refer to access systems, which support
active handover and associated forwarding between radio accesses.
Do you think we should include such a reference?

Thanks and best regards,
marco

>  
> Best regards,
> Pierrick
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mipshop
>

---

From: <[email-masked]>
Date: Tue, 21 Apr 2009 22:59:31 +0200

Hi Marco,

Thanks for clarifications. Please see inline for more comments.

Regards,
Pierrick
> -----Message d'origine-----
> De : Marco Liebsch [mailto:[email-masked]]
> Envoyé : lundi 20 avril 2009 12:25
> À : SEITE Pierrick RD-RESA-REN
> Cc : [email-masked]
> Objet : Re: [Mipshop] comments on draft-ietf-mipshop-transient-bce
> 
> Hi Pierrick,
> 

Ok, I see.

> example). Maybe a good idea to include one or two examples as note?

Yes, an example could help.
 
> also be used for wired access. If you think this is confusing, we could

Ok, I agree it is worth keeping keep the wired access in the scope 

> show the radio access forwarding between previous and target access?

Well, single radio use-case is not as clear as dual radio. Sure, A1 helps to describe the problem, but, as you suggest, more details could help to clarify.
 
> case (LMA controlled transient BCE) more?
Yes, I think this configuration could be highlighted even the document already allows the LMA to control transient state and introduce the concept pf LMA policy.

> L-flag but to allow the LMA to 'add' setting the A-flag? 

Yes, that's one possibility.

That's ok from
> set up completely. Performance will be in any improve compared to RFC5213.

Ok, I understand.

> for the single radio HO we just refer to access systems, 

Well, it is the annex, so, I think a reference to 3GPP is not a problem here and it would clarify the use case.

which support

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 22 Apr 2009 10:23:02 +0200

Hi Pierrick,

please see inline.

> Yes, an example could help.
Ok, we'll add a note here. Good point.

Ok.

> Well, single radio use-case is not as clear as dual radio. Sure, A1 helps to describe the problem, but, as you suggest, more details could help to clarify.
Good, we'll try to be more clear with that use case.

> Yes, I think this configuration could be highlighted even the document already allows the LMA to control transient state and introduce the concept pf LMA policy.
I think the operation of LMA-controlled cases is covered in the MAG 
options and LMA operation
section. Maybe we can highlight this operation more in the General 
Protocol Operation section as well.
So far it's somehow in the background. Will take care of that.

>> my point of view and can easlity be added. Thanks!
Ok, could make sense. In any case, detailed configuration of a transient 
phase
is known to the nMAG only after the completed PBU/PBA handshake.
 From operations point of view, this split makes sense. I am ok with
adding this, but will try to poll more opinions. Thanks for pointing to
this.

> Well, it is the annex, so, I think a reference to 3GPP is not a problem here and it would clarify the use case.
True. Ok, we'll take a reference into account.

Thanks again for the useful comments and input.

Best regards,
marco