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

[Xiangsong Cui <[e-mail]>]

Hi Sri,
Please see inline.

Thanks and regards

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


>
>
> On Thu, 16 Jul 2009, Xiangsong Cui wrote:
>
>> 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.
>>
>
> 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?

> When a new message arrives, drop the existing one and process the
> 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
> 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 ?
I am not sure which one is better.

>
> Sri
>
>
>
>> Thanks
>>
>> Xiangsong
>>
>>
>> ----- Original Message ----- From: "Sri Gundavelli" <[e-mail]>
>> To: "'Xiangsong Cui'" <[e-mail]>
>> Cc: <[e-mail]>; <[e-mail]>
>> Sent: Thursday, July 16, 2009 8:45 AM
>> Subject: Re: [netext] Discussion about "Retransmit Message Identifier 
>> Option"//Re: Agenda Requests received
>>
>>
>>>  Hi Xiangsong,
>>>
>>> >  -----Original Message-----
>>> >  From: Xiangsong Cui [mailto:[e-mail]]
>>> >  Sent: Wednesday, July 15, 2009 12:01 AM
>>> >  To: Sri Gundavelli
>>> >  Cc: [e-mail]; [e-mail]
>>> >  Subject: Re: Discussion about "Retransmit Message Identifier
>>> >  Option"//Re: [netext] Agenda Requests received
>>> >
>>> >  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.
>>> >
>>>
>>>  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.
>>>
>>>
>>> >  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?
>>>
>>>  Deep. Dont get it.
>>>
>>>
>>> >
>>> >  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?
>>> >
>>>
>>>  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
>>>
>>>
>>>
>>> >  Regards/Xiangsong
>>> >
>>> >  =======================================================
>>> >  ----- Original Message ----- From: "Sri Gundavelli" 
>>> > <[e-mail]>
>>> >  To: "Xiangsong Cui" <[e-mail]>
>>> >  Cc: <[e-mail]>; <[e-mail]>
>>> >  Sent: Wednesday, July 15, 2009 1:22 PM
>>> >  Subject: Re: Discussion about "Retransmit Message Identifier
>>> >  Option"//Re:
>>> >  [netext] Agenda Requests received
>>> >
>>> >
>>> > >  Hi  Xiangsong,
>>> > >
>>> > >  Please see inline.
>>> > >
>>> > >  On Wed, 15 Jul 2009, Xiangsong Cui wrote:
>>> > >
>>> > > >  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:
>>> > > >
>>> > >
>>> > >  Sorry, we missed that.
>>> > >
>>> > >
>>> > > >  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?
>>> > > >
>>> > >
>>> > >  Yes
>>> > >
>>> > > >
>>> > > >  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.
>>> > > >
>>> > >
>>> > >  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:
>>> > > >      -----------------------------------------
>>> > > >      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.
>>> > > >
>>> > >
>>> > >  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
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > >
>>> > > >  Because I will not go to the meeting, I want to discuss
>>> >  the topic in list
>>> > > >  before the meeting.
>>> > > >
>>> > > >  Thanks and regards
>>> > > >
>>> > > >  Xiangsong
>>> > > >
>>> > > >  =================================================
>>> > > >  ----- Original Message ----- From: <[e-mail]>
>>> > > >  To: <[e-mail]>; <[e-mail]>
>>> > > >  Sent: Wednesday, July 15, 2009 1:34 AM
>>> > > >  Subject: Re: [netext] Agenda Requests received
>>> > > >
>>> > > >
>>> > > > >
>>> > > > >  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
>>> > > > >
>>> > > > >   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
>>> > > > >
>>> > > > >   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
>>> > > > >
>>> > > > >   _______________________________________________
>>> > > > >   netext mailing list
>>> > > > >   [e-mail]
>>> > > > >   https://www.ietf.org/mailman/listinfo/netext
>>> > > >
>>> > > >
>>> >
>>>
>>>  _______________________________________________
>>>  netext mailing list
>>>  [e-mail]
>>>  https://www.ietf.org/mailman/listinfo/netext
>>
>>
>>