RE: [802.21] Ad-hoc on ES/CS discussion
Hi all,
Yoshi brought up a use case with MIH_Switch. But there are other broader
use cases involving MIH event services, which are defined to be one way
indications. On the other hand, in ES/CS discussion we have clearly
stated that there is no requirement for a reliable transport underneath.
I agree that it is still possible to have a reliable transport(e.g. L2),
but so are unreliable transports e.g. L3. So the MIH protocol should
provide the flexibility to work in these different transport
environments, what better way than to leave the decision to the
originating party by use of some indication in the request? The response
would be a general MIH_ACK packet associated to the received message.
This is a small packet, a simple solution is to use a bare MIH packet
with some field setting and same transaction id. Ofcourse, other
solutions are welcome.
Regards,
Srini
>-----Original Message-----
>From: ext Phillip Barber [mailto:pbarber@BROADBANDMOBILETECH.COM]
>Sent: Friday, February 17, 2006 2:30 PM
>To: STDS-802-21@listserv.ieee.org
>Subject: [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
>>>>
>>>
>>
>