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

["Sri Gundavelli" <[e-mail]>]

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
> >>
> >> 
>