[802.21] Ad-hoc on ES/CS discussion
Just don't go crazy putting ACKs into the messaging model. Sometimes they
are appropriate, sometimes not. For those that implement a reliable
transport method like SCTP or UDP, putting ACKs onto everything just
confuses the timers and state machines.
Thanks,
Phillip Barber
Chief Scientist
Broadband Wireless Solutions
Huawei Technologies Co., LTD.
> ----- Original Message -----
> From: "Gupta, Vivek G" <vivek.g.gupta@INTEL.COM>
> To: "Yoshihiro Ohba" <yohba@tari.toshiba.com>; "Eunah Kim"
> <eakim@ETRI.RE.KR>
> Cc: <STDS-802-21@listserv.ieee.org>
> Sent: Friday, February 17, 2006 2:10 PM
> Subject: RE: [802.21] Ad-hoc on ES/CS discussion
>
>
>> Should such an ACK occur at MIH level or at transport level?
>> 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.
>>
>> You could have something similar at L3 as well.
>> Is there a need to define ACK opcode at MIHF level? (Nope)
>>
>> 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
>>>
>>
>