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

[Xiangsong Cui <[e-mail]>]

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