Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.21] Ad-hoc on ES/CS discussion



Hi Vivek,

On Fri, Feb 17, 2006 at 12:10:38PM -0800, Gupta, Vivek G wrote:
> 
> Should such an ACK occur at MIH level or at transport level?

At MIH level.  Of course ACK is not needed if the transport is
reliable.

> If you are using L2 transport for sending these MIH messages, for each
> message (command, indication etc.) you shall get an ACK at L2 transport
> level. That should be good enough.

Right, ACK is not needed for such reliable L2 transport.

> 
> You could have something similar at L3 as well.
> Is there a need to define ACK opcode at MIHF level? (Nope)

If the tranport is UDP, ACK is needed at MIHF level.

Regards,
Yoshihiro Ohba


> 
> Best regards,
> -Vivek
> 
> > -----Original Message-----
> > From: stds-802-21@ieee.org [mailto:stds-802-21@ieee.org] On Behalf Of
> > Yoshihiro Ohba
> > Sent: Friday, February 17, 2006 12:53 AM
> > To: Eunah Kim
> > Cc: STDS-802-21@listserv.ieee.org
> > Subject: 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
> > 
> 
>