Subject: [netext] Agenda Requests received

From: <[email-masked]>
Date: Tue, 14 Jul 2009 01:37:51 +0200

The following are the agenda requests received so far.

Agenda requests received:

1. Runtime LMA Assignment Support for Proxy Mobile IPv6"
   I-D: draft-korhonen-netext-redirect-02
   Jouni Korhonen - 10 Mins

2. Localized Routing
   PMIPv6 Localized Routing Problem Statement
   I-D: draft-liebsch-netext-pmip6-ro-ps-01.txt
   PS and Scope discussion    10 Mins
   Solutions        15 Mins
   Marco Liebsch et al.

   Proxy MIP extension for local routing optimization
   I-D: draft-wu-netext-local-ro-02.txt
   Behcet Sarikaya    5 Mins

3. Tunnel Negotiation for Proxy Mobile IPv6
   I-D: draft-xia-netext-tunnel-negotiation-01.txt
   Frank Xia        10 Mins

4. Mobile Node Group Identifier Option:
   I-D: draft-gundavelli-netext-mn-groupid-option-01
   Sri Gundavelli    10 Mins

5. Retransmit Message Identifier Option:
   I-D: draft-gundavelli-netext-pmipv6-retransmit-option-00.txt
   Sri Gundavelli    10 Mins

6. Mobility session suspend
   I-D: draft-muhanna-netext-mobility-session-suspend-00.txt
   Ahmad Muhanna    10 Mins

7. Trace Control Support for Proxy Mobile IPv6
   I-D: draft-wang-netext-trace-control-00.txt
   Yungui Wang        10 Mins

8. Multihoming extensions for Proxy Mobile IPv6
   I-D: draft-bernardos-mif-pmip-00.txt
   Telemaco, Pierrick and Carlos    10 Mins

9. 3GPP MN-AR interface
   I-D: draft-melia-netext-3gpp-mn-ar-if-00.txt
   Telemaco                5 Mins

-Chairs

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Tue, 14 Jul 2009 08:03:33 +0800

Dear Chairs,

Can we have 5 to 10 minute slot to present the 

draft-jeyatharan-netext-PMIP-Partial-Handoff ID.

Thanks.

BR,
Mohana

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of [email-masked]
> Sent: Tuesday, July 14, 2009 7:38 AM
> To: [email-masked]
> Subject: [netext] Agenda Requests received
> 
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: <[email-masked]>
Date: Tue, 14 Jul 2009 02:15:30 +0200

I think it would be better to wait for the outcome of the NetExt2 BoF before
considering this I-D on the agenda of the WG meeting.

-Raj

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Tue, 14 Jul 2009 08:19:26 +0800

Hi Raj,

Well, if you think we should wait for the outcome of NetExt2 BoF, it is
fine.  But if you have some spare time in the NetExt meeting please
consider this presentation.

Thanks.

BR,
Mohana

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, July 14, 2009 8:16 AM
> To: Mohana Jeyatharan; [email-masked]
> Subject: Re: [netext] Agenda Requests received
> 
>

---

From: <[email-masked]>
Date: Tue, 14 Jul 2009 19:34:55 +0200

As of 7/14 the chairs have received requests for agenda slots at IETF75.
We would like to encourage WG members to review the I-Ds and provide
feedback on the list prior to the meeting itself.

-Chairs

1. Runtime LMA Assignment Support for Proxy Mobile IPv6
   I-D: draft-korhonen-netext-redirect-02
   Jouni Korhonen - 10 Mins

2. Localized Routing

9. 3GPP MN-AR interface

10. Service Flow Identifier in Proxy Mobile IPv6
    I-D: draft-hui-netext-service-flow-identifier-00.txt
    Min Hui        10 Mins

11. Connection Identifier for Proxy Mobile IPv6
    I-D: draft-wolfner-netext-pmip6-connid-00
    Jouni Korhonen    5 Mins

12. Bulk Re-registration for Proxy Mobile IPv6
    I-D: draft-premec-netlmm-bulk-re-registration-02
    Jouni Korhonen    5 Mins

13. Partial Handoff Support in PMIPv6
    I-D: draft-jeyatharan-netext-pmip-partial-handoff-00
    Mohana Jeyatharan

---

From: Xiangsong Cui <[email-masked]>
Date: Wed, 15 Jul 2009 12:52:26 +0800

Good idea.

I have a question about item 5, "Retransmit Message Identifier Option".
I ever posted a mail on 27 June, but it was ignored. So I copy the mail 
here:

The draft says:
----------------------------------------
1.  Introduction

   The Proxy Mobile IPv6 protocol [RFC-5213] does not provide the
   ability for the sender of a signaling message to mark retransmitted
   messages with a proper tag, so the receiver can differentiate between
   the original message to a retransmitted message.  This semantic is
   important for the receiver to determine when to ignore processing a
   retransmitted packet, or for various other reasons.
---------------------------------------------

Is the motive is just to distinguish the original and retransmitted PBU?

I ask this question just because I think it is unnecessary. The reason is:

1, section 6.1.7 [RFC3775] shows there is a "Sequence #" field in BU
message, and
   section 11.8 [RFC3775] says:
   --------------------------------------------------------
      Retransmitted Binding Updates MUST use a Sequence Number value
   greater than that used for the previous transmission of this Binding
   Update.
   ----------------------------------------------------
   So the BU messages are different for their sequence number.

2,  section 6.6 [RFC5213] says:
     -----------------------------------------
     6.6.  Acquiring Mobile Node's Identifier

   All the network entities in a Proxy Mobile IPv6 domain MUST be able
   to identify a mobile node, using its MN-Identifier.  This identifier
   MUST be stable and unique across the Proxy Mobile IPv6 domain.  The
   mobility entities in the Proxy Mobile IPv6 domain MUST be able to use
   this identifier in the signaling messages and unambiguously identify
   a given mobile node.  The following are some of the considerations
   related to this MN-Identifier.
   -------------------------------------------
   In [RFC3775] LMA MUST distinguish the mobile node by the MN-ID.
   PBU message format also shows there is a sequence # field in PBU
   message and "Mobile Node Identifier option" is valid.

3, section 6.9.4 [RFC5213] has specified the rule for Retransmissions and
Rate Limiting.

For these reasons, I believe the LMA can recognize the duplicate PBUs.
The LMA has been capable of making binding for the first PBU and ignore
other PBUs for the same mobile node.

Do I make any mistakes? and why we need a new extension?

Because I will not go to the meeting, I want to discuss the topic in list
before the meeting.

Thanks and regards

Xiangsong

=================================================

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 14 Jul 2009 22:22:45 -0700 (PDT)

Hi  Xiangsong,

Please see inline.

On Wed, 15 Jul 2009, Xiangsong Cui wrote:

> I ever posted a mail on 27 June, but it was ignored. So I copy the mail here:
>

Sorry, we missed that.

> The draft says:

Yes

>   section 11.8 [RFC3775] says:

We need the ability to distinguish between a original message to a
retransmitted request. Lets take the case, LMA receives a PBU and
is in the midst of processing that request and a second message
arrives. There is nothing in the message which allows the receiver
to identify this message as a retransmit of the current message
that is being processed. If you go with the seq num, or the time
stamp, each message has a different values of those options. What
we need is a tag that allows the LMA to see this marking and associate
with the earlier request. In some interop, there was a case where
the MAG was retransmitting a request and ignoring the response for
an earlier sent request. This could  be avoided, if there are such
semantics for tagging retransmitted messages.

> 2,  section 6.6 [RFC5213] says:

The rules in 6.9.4 is for addressing the MAG contention issue. Its not
about detecting duplicate messages. Its more of an out-of order delivery
issue.

> Do I make any mistakes? and why we need a new extension?

These are good questions. The goal is to have a tag on retransmitted
packets. This simple option provides such semantic. Relevant or not,
such semantics are even present in protocols such as GTP.

Regards
Sri

> ----- Original Message ----- From: <[email-masked]>

---

From: Xiangsong Cui <[email-masked]>
Date: Wed, 15 Jul 2009 15:00:43 +0800

Hi Sri,

Thank you for your response.
I think I got your meaning but I really don't know why we need it.
Let's look into the precise details.

An assumed case:
1,  At time T [in ms], MAG send a PBU to LMA,
     with SN, timestamp T and lifetime 30 second;
2,  At time (T+1000), MAG resend a PBU to LMA, // retransmission in 1 second
     with (SN+1), timestamp (T+1000) and lifetime 30 second
3,  At time (T+1020), first PBU arrives at LMA;
4,  At time (T+1050), second PBU arrives at LMA.

In my mind, as RFC5213 and RFC3775, LMA must process
the second PBU, even if it has already processed the first one,
because the timestamp is greater than the first one.

As your draft, LMA may or should ignore the second PBU,
because MAG insert a retransmission tag in the PBU.

But by now, some difference, a very little difference happens.
In RFC solution, lifetime in LMA expires at (T+1050+30000) ,
while in your draft solution, lifetime expires at (T+1020+30000).

Is that right?

I think there is no bug in original solution, but your modification
bring a different behavior and different result.
In my thought, all registration with lifetime in IETF protocols, are
with the same character.
But now your draft solution bring a modification, making NETEXT
protocol different from MIP, PMIP, SIP or other protocols.

I'm not sure, is it a bug need us to do a such fix?

Regards/Xiangsong

=======================================================
----- Original Message ----- 
From: "Sri Gundavelli" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 15, 2009 1:22 PM
Subject: Re: Discussion about "Retransmit Message Identifier Option"//Re: 
[netext] Agenda Requests received

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 15 Jul 2009 17:45:47 -0700

Hi Xiangsong, 

> From: Xiangsong Cui [mailto:[email-masked]] 
> Sent: Wednesday, July 15, 2009 12:01 AM
> To: Sri Gundavelli
> Cc: [email-masked]; [email-masked]
> Subject: Re: Discussion about "Retransmit Message Identifier 
> Option"//Re: [netext] Agenda Requests received
> 
> Hi Sri,
> 

Exactly. In the event, when these two messages are sent for
the exact purpose, if the HA can determine that its a duplicate,
it can just complete processing the first request and send a
reply and it can even tag the response as the response to the
latest. The MAG and the LMA have clear semantics on the handling
retransmit messages. Without the option, every message has to
be treated differently and the latest has the precedence. With
the retransmit option, the peers know what messages can be
safely ignored based on the retransmit tags.

> while in your draft solution, lifetime expires at (T+1020+30000).

Deep. Dont get it.

> I'm not sure, is it a bug need us to do a such fix?

Its not about a bug. As I keep saying, the sender and receiver need
to have the ability to differentiate between a new request to a
retransmit request, either because the retransmit times and the
processing times are not synchronised or when the messages are lost.
The tag is a simple marker.

Regards
Sri

> >> I ask this question just because I think it is 
> unnecessary. The reason 
> >> is:
> >>

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 16 Jul 2009 09:18:43 +0800

Yes, I agree it is a very simple tag.
I just don't understand what benefit we can get from the extension.
That's all my question.

Thanks

Xiangsong

----- Original Message ----- 
From: "Sri Gundavelli" <[email-masked]>
To: "'Xiangsong Cui'" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, July 16, 2009 8:45 AM
Subject: Re: [netext] Discussion about "Retransmit Message Identifier 
Option"//Re: Agenda Requests received

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 15 Jul 2009 18:23:56 -0700 (PDT)

> I just don't understand what benefit we can get from the extension.

So, you are saying, LMA has no need to identify retransmitted packets ?
When a new message arrives, drop the existing one and process the
new message. The sender receives reply for the older message and it
should drop and send a new request ? In this scenario is it not better
for the sender and receiver to have an understanding of what is being
processed and what is the new message for and its relation to the
older message ?

Sri

> Thanks
>
> Xiangsong
>
>
> ----- Original Message ----- From: "Sri Gundavelli" <[email-masked]>
>> >  ----- Original Message ----- From: "Sri Gundavelli" <[email-masked]>

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 16 Jul 2009 10:10:23 +0800

Hi Sri,
Please see inline.

Thanks and regards

----- Original Message ----- 
From: "Sri Gundavelli" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, July 16, 2009 9:23 AM
Subject: Re: [netext] Discussion about "Retransmit Message Identifier 

> So, you are saying, LMA has no need to identify retransmitted packets ?
I think LMA need identify the packets, but need not care the intention.
Maybe it is the retransmitted message, maybe a new one, what is the
difference for LMA?

> new message.
Maybe drop the existing one, or maybe process both messages (I think
latter is the right way in RFCs) and responds two binding Ack message.

> The sender receives reply for the older message and it
> should drop and send a new request ?
Yes, sender will receive reply message, maybe one or two response.
If sender send two request, one is for binding and the other one is for
retransmission, I think there is only one timer and only one timer for
retransmission in the sender. If the sender receives reply message, it
has achieved the registration and it must kill the timer, and will not
retransmit request any more.
This is the key point, Do you agree it?
If the timer has been killed, I don't know why the sender will send a
new request.

> In this scenario is it not better
I am not sure which one is better.

>>> > > > >  As of 7/14 the chairs have received requests for agenda slots 
>>> > > > > at
>>> > > > >  IETF75.

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 15 Jul 2009 21:14:07 -0700 (PDT)

Hi Xiangsong,

> Maybe it is the retransmitted message, maybe a new one, what is the

It makes a difference. When the LMA is waiting for a AAA response or
waiting for some other resource, this distinction will be critical.
A response that it constructs, can simply be sent as a response to
the latest request, if it knows that the newly recvd request and
the request under processing are the same. The MAG would always
be able to know that the response that is received is the response
for the latest. With the current lack of semantics, there can be
cases where the MAG keeps sending requests, LMA keeps responding
as it processes and the MAG still waiting for the latest response.

> latter is the right way in RFCs) and responds two binding Ack message.

But, the current text is not considering this scenario. There is
not much consideration given to retransmit packets.

> If the timer has been killed, I don't know why the sender will send a

But, there is a req to reply corelator when using seq numbers, that
wont match.

> I am not sure which one is better.

The bigger question would be do we need the ability to understand
the sender intent and benifit in the processing logic in knowing
the same, and avoiding the looping issue.

Sri

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 16 Jul 2009 13:19:28 +0800

Hi Sri,

I think we meet some key detail in MAG.
Maybe they are implement issues

How does MAG start its timer for binding request?
case 1: ONLY one timer for the binding request thread; or
case 2: One timer for per binding request message.

I prefer the case 1, and in case 1, as I said no trouble happen.
Without multi-homing, MAG and LMA can identify the thread
by source IP address and destination IP address,
if with multi-homing, BID may be plus to identify the thread.
In case 1, MAG and LMA identify request/response by thread,
but not by sequence number. One reply can kill the thread timer.
So only one timer starts and SN mismatch will not happen in case 1.

In case 2, multi timer are started for multi request messages, and
SN is used to identify message.
If only one response returned as your solution, what will happen?
some timer still running (because only reply SN timer is killed) and
requests are sent in period.
Looping issue will happen in this case, if your solution is applied.

By the way, if you just want to distinguish original request and
retransmitted request, I have another idea, without any message
or option format modified in the protocol.

We can claim a rule or suggestion:
When MAG retransmits a binding request, it uses the original
timestamp, as the value in original request message.
For LMA, when a binding request message is received,
timestamp is checked:
If new-arrived timestamp is greater, new request;
if new-arrived timestamp is equal, duplicate request, ignore or other 
process.
if new-arrived timestamp is less, old request, drop it.

Timestamp details is missed in RFCs, there are only sequence number 
increase.
We can highlight the rule or suggestion in bis version.

How do you think about the idea?

Xiangsong

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 20 Jul 2009 10:29:30 +0200

Hi Xiangsong, Sri,

> case 2: One timer for per binding request message.
I think the result is the same, as the MAG retransmits only after the 
retransmit timer
has fired. I think there is implicitly only one timer scheduled in the 
context of
one binding. If there is some good reason to send an updating PBU before the
PBA for the previous PBU has been received, it's not a retransmission 
anymore.

> Timestamp details is missed in RFCs, there are only sequence number 
RFC5213 mandates using the latest timer in a retransmit PBU. The mechanism
you propose may work, but conflicts with the original meaning of a 
timestamp.
However, using the previous timestamp in retransmits may work, and it still
works for the handover scenario, where timestamps should resolve 
potential race
conditions. Even if a pMAG uses in a retransmit message not the actual 
but the
original timestamp, the timestamp of the nMAG is always higher.

I've more doubts in how realistic the problem is that should be resolved 
with
the retransmit tag? Is this a case that happened in real testbed and did 
it cause
serious issues? I think it introduces some complexity, whereas the benefit
is less. At least there is no benefit in protocol stability when 
introducing such
identification of retransmit packets. Ok, the only benefit I see is to 
reply only to the
latest retransmit, which is not a huge gain.

My 2 cents,

marco

>>> Subject: Re: [netext] Discussion about "Retransmit Message 
>>> Identifier Option"//Re: Agenda Requests received
>>>
>>>
>>>>

---

From: Xiangsong Cui <[email-masked]>
Date: Mon, 20 Jul 2009 17:40:43 +0800

Hi Marco,

Please see inline.

Regards/ Xiangsong

----- Original Message ----- 
From: "Marco Liebsch" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, July 20, 2009 4:29 PM
Subject: Re: [netext] Discussion about "Retransmit Message Identifier 

> PBA for the previous PBU has been received, it's not a retransmission 

Yes, I agree there is only one timer is running, but the different timer has
different meaning in fact. So the result maybe different.
If the timer is for the given request message, the timer is associated with
the request message. Whether the sequence number is used to match the
message and timer is an implement issue.

For example, if sender sends a request SN, and starts a timer(SN).
When timer(SN) expires, the sender resends request SN+1, and starts 
timer(SN+1).
When the sender receives binding Ack with SN, is it can kill timer(SN+1)?
I ever see an acknowledgement with SN can ack Cumulative sequence numbers
that equal or less than SN, but I never see a SN ack message can acknowledge 
a
request with number SN+1.

So, I prefer the LMA responds the latter request, and acknowledge the 
greater
sequence number.

> you propose may work, but conflicts with the original meaning of a 

I really want to find the content in RFC for the issue, can you tell me
where is the conflicts? which section in RFC5213 should I read?

I ever found a description in 3GPP TS29.275 v8.3.0(PMIPv6, Stage 3) ,
in subclause 5.3.1.2,  Table 5.3.1.2-2: Mobility Options in a PBA message
for the PMIPv6 PDN Connection Handover procedure.
For Timestamp option,  it says "Copied from corresponding field of PBU,
or set to the current time of LMA in case of timestamp error".
I think since the Ack message keeps the same timerstamp in request,
so the retransmitted PBU keep the same original timerstamp is also 
reasonable.

> works for the handover scenario, where timestamps should resolve potential 
> race
> conditions. Even if a pMAG uses in a retransmit message not the actual but 
> the
> identification of retransmit packets.

I agree with you on this point.

> Ok, the only benefit I see is to reply only to the

I also agree with you on this point, if only reponse, I prefer the latest.

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 20 Jul 2009 14:28:33 +0200

Hi Xiangsong,
please find some reply inline.

marco

Xiangsong Cui schrieb:
> Hi Marco,
>
> Please see inline.
>
> Regards/ Xiangsong
>
>
> ----- Original Message ----- From: "Marco Liebsch" <[email-masked]>
>> has fired. I think there is implicitly only one timer scheduled in 
>> the context of
Hmm, but the packet carries a different sequence number than the packet 
which has
the timer scheduled for. And if a MAG really behaves like you said, then 
the MAG
could be satisfied, as it received at least a PBA for a registration in 
the same context.
If it receives a PBA for the restransmit PBU, well, tht could be ignored 
then. So it does
not matter if the retransmit message has a timer scheduled or not, or?

> that equal or less than SN, but I never see a SN ack message can 
> acknowledge a
>>> if new-arrived timestamp is equal, duplicate request, ignore or 
>>> other process.

6.9.4 sais:

4.  If the Timestamp-based scheme is in use, the retransmitted Proxy
       Binding Update messages MUST use the latest timestamp.  

I read this as to use a new timestamp for the retransmit packet.
Btw, this is about the MAG.

In general, I see timestamps to a packet as stamp when the packet is 
sent. According
to my knowledge, also IEEE 802.11 puts timestamps only when the packet
is about to be transmitted on the radio. I just interpret using an 
out-of-date
(better: out-of-time ;-) timestamp as conflict with that. Does not mean 
that it
cannot be changed.

>> conditions. Even if a pMAG uses in a retransmit message not the 
>> actual but the
>> I've more doubts in how realistic the problem is that should be 
>> resolved with
>> the retransmit tag? Is this a case that happened in real testbed and 
>> did it cause

---

From: Xiangsong Cui <[email-masked]>
Date: Tue, 21 Jul 2009 09:09:23 +0800

Hi Marco,

Thank you for your response, please see inline.

Regards
Xiangsong

----- Original Message ----- 
From: "Marco Liebsch" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>
Cc: "Marco Liebsch" <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Monday, July 20, 2009 8:28 PM
Subject: Re: [netext] Discussion about "Retransmit Message Identifier 
Option"//Re: Agenda Requests received

> not matter if the retransmit message has a timer scheduled or not, or?
I think this a implement issue,
I assume the case 2 is using one timer match one message,
and the case 1 is using one timer match one request thread, i.e. one 
context.

Maybe there is only one case in fact.
I think we can stop discussing it now.

> In general, I see timestamps to a packet as stamp when the packet is sent. 
> According
Yes, I got it, thank you.

Xiangsong

---

From: Xiangsong Cui <[email-masked]>
Date: Wed, 22 Jul 2009 17:58:06 +0800

I have a question about the item #12,
the draft "bulk-re-registration".

In the section 1, there is a formula:
transactions/sec = (number of registered MNs) / (binding lifetime*4) 
I don't understand it, why we multiply lifetime by 4?

In my mind, there are two messages in the re-register flow, a PBU 
message and a PBA message, and the re-register interval is the lifetime.
A PBU and a PBA also constitutes one transaction.
So, for one MN, in the duration of the lifetime, there are two messages,
and the message rate is:   message/sec = 2/lifetime,
the transaction rate is:   transaction/sec = 1/lifetime.
For a MAG or a LMA, the total transaction rate is:
transactions/sec = (number of registered MNs) / binding lifetime.

Is it right?

Regards
Xiangsong

---

From: jouni korhonen <[email-masked]>
Date: Wed, 22 Jul 2009 14:14:24 +0300

Hi Xiangsong,

> I don't understand it, why we multiply lifetime by 4?

The lifetime is expressed as a unit of 4 seconds. See Section 6.1.7.  
of RFC3775. The 'lifetime' here means the value inside the PBU message.

Cheers,
	Jouni

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 23 Jul 2009 09:27:19 +0800

I see, thank you very much.

Xiangsong