Re: [802.21] Ad-hoc on ES/CS discussion
Hi Eunah,
The ACK concept originally came up during private discussion with
Qiaobing, Mathieu, etc. Specifically the issue was that MIH_Switch
command can take time to process. Without ACK, the sender of
MIH_Switch.request cannot tell whether the request gets lost or the
request has been received but is taking time to process. Now with
ACK, the sender can avoid unnecessary retransmission of the request
once it receives an ACK for the request. ACK is also useful for event
indications.
Yes, ACK is useful only if the underlying transport is unreliable.
That is why the use of ACK is optional, i.e., 'a'-flag can be always
unset in case the underlying transport is reliable.
I agree that some TIMER is needed to retransmit the message when
ACK is requested but not returned in time.
Best regards,
Yoshihiro Ohba
On Fri, Feb 17, 2006 at 03:21:26PM +0900, Eunah Kim wrote:
> Hi Yoshi,
>
> Actually, we didn't discuss ACK message during yesterday's telecon due to the lack of time.
>
> By the way, I wonder why we need this ACK mechanism.
> For the request message, the response can be treated as the corresponding acknowledgement.
> And I think ACK concept is useful when the transport is not reliable.
> Are we(or access technologies) in this situation?
> If yes, I'd like to suggest to use TIMER mechanism for receiving ACK message as well.
>
> Regards,
> Eunah
> ----- Original Message -----
> From: Srinivas Sreemanthula
> To: STDS-802-21@LISTSERV.IEEE.ORG
> Sent: Friday, February 17, 2006 5:57 AM
> Subject: Re: [802.21] Ad-hoc on ES/CS discussion
>
>
>
> Hi Yoshi,
>
> The intention of the primitive is not over MIH_SAP or LINK_SAP but only
> for internal MIH use. I am okay to extend the ACK concept to req/resp.
> It will be useful in certain scenarios. We can add the flag for ACK
> request in the header. I would like to get other's opinion on the Opcode
> part. I am personally okay with it and modifying the header.
>
> Regards,
> Srini
>
> >-----Original Message-----
> >From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> >Sent: Thursday, February 16, 2006 10:07 AM
> >To: Sreemanthula Srinivas (Nokia-NRC/Dallas)
> >Cc: STDS-802-21@LISTSERV.IEEE.ORG
> >Subject: Re: [802.21] Ad-hoc on ES/CS discussion
> >
> >I have comments on ACK message.
> >
> >I agree with defining ACK mechanism. On the other hand, ACK
> >is useful not only for event indication transaction but also
> >request/response transactions.
> >
> >- ACK does not have to be defined as a primitive. It can be
> >part of general message handling within MIHF implementation.
> >
> >- An ACK can be returned for any request, response and
> >indication message as a receipt of the message.
> >
> >Having said that, my suggestion is:
> >
> >- define a new OpCode for ACK in the MIH fixed header.
> >
> >- define a new flag 'a'(cknowledgment required) in the MIH
> >fixed header.
> >
> >Semantics: If the sender of a request, response and indication
> >message requires an ACK, then it sets 'a' flag in the message.
> > If the receiver of a request, response and indication message
> >finds that 'a'
> >flag is set, then it returns an ACK using OpCode=ACK, copying
> >the received Transaction ID to the Transaction ID field and
> >with empty payload. The use of ACK is controlled by within
> >each MIHF implementation and transparent to the MIH users (no
> >primitives need to be defined). An ACK MUST NOT be returned
> >in response to an ACK.
> >
> >If this makes sense, I can reflect this into my contribution
> >on MIH header issue as D05 comment.
> >
> >What do you think?
> >
> >Yoshihiro Ohba
> >
> >
> >
> >On Thu, Feb 16, 2006 at 01:14:08AM -0600, Srinivas Sreemanthula wrote:
> >> Hello,
> >> Here is the document from previous discussions. I have made some
> >> changes
> >> (highlighted) based on the ongoing email discussions. I encourage to
> >> discuss the relevant hot button issues and arrive to a conclusion.
> >>
> >> Regards,
> >> Srini
> >>
> >>
> >> ________________________________
> >>
> >> From: ext Srinivas Sreemanthula
> >> [mailto:Srinivas.Sreemanthula@nokia.com]
> >> Sent: Wednesday, February 15, 2006 5:27 PM
> >> To: STDS-802-21@listserv.ieee.org
> >> Subject: [802.21] Ad-hoc on ES/CS discussion
> >>
> >>
> >> Hello participants,
> >> Here is the adhoc telecon information for tomorrow
> >(2/16) regarding
> >> ES/CS information. Primarily the discussion is related to
> >registration
> >> and related aspects like MIH ID, session ID etc. If time permits, we
> >> could include the ACK discussion.
> >>
> >> Regards,
> >> Srini
> >>
> >> Name of the conference: IEEE 802.21 ES/CS Discussions
> >>
> >> Time: 8-10am CT
> >>
> >> Conference ID: 59489, PIN: 110483
> >>
> >> US Phone Number: 972-894-6500
> >>
> >> EU Phone Number: +358 7180 71870
> >>
> >> Type of reservation: Single reservation: 16.02.2006
> >>
> >> (GMT-06:00) Central Time (US & Canada)
> >>
> >> Number of participants: 20
> >>
> >> Instructions language: English
> >>
> >> Features: participant's identification
> >>
> >
> >
> >