RE: [802.21] Ad-hoc on ES/CS discussion
Hi,
My two cents here. I agree we should not make MIH protocol too heavy.
However, just stating "use TCP" if you want reliability is not a valid
answer. If we really want to be able to send a command at any time
during a "ES/CS registration session" from the network to the terminal,
since the node generating the message may be remote we need to consider
aspects such as FW and NAT traversal. In fact, if the state in the FW or
NAT expires, the message would not get to the terminal. To keep the
state alive, "keepalive" solutions may be needed at the MIH level.
Besides being a "dirty" solution, keep alive may have impact on other
aspects (e.g. power saving for terminals that are temporarily idle).
Overall, the thing may get worst than with having the ACKs.
Stefano
>-----Original Message-----
>From: ext Srinivas Sreemanthula
>[mailto:Srinivas.Sreemanthula@nokia.com]
>Sent: Monday, February 20, 2006 1:34 PM
>To: STDS-802-21@listserv.ieee.org
>Subject: Re: [802.21] Ad-hoc on ES/CS discussion
>
>TCP works fine but if we had UDP, how can MIH guarantee that
>an event or command is delivered reliably? Alternative is to
>require a reliable transport, assuming TCP, we analysed that
>this may result in a lot of overhead (in number of exchanges
>and time) for one MIH ES/CS message, which can be time
>sensitive. Any other ideas?
>
>Regards,
>Srini
>
>>-----Original Message-----
>>From: ext Gupta, Vivek G [mailto:vivek.g.gupta@intel.com]
>>Sent: Monday, February 20, 2006 12:58 PM
>>To: Sreemanthula Srinivas (Nokia-NRC/Dallas);
>>pbarber@BROADBANDMOBILETECH.COM; STDS-802-21@listserv.ieee.org
>>Subject: RE: [802.21] Ad-hoc on ES/CS discussion
>>
>>
>>There is no reason why MIH messaging cannot work at L3 both with
>>TCP/UDP. However as Phil pointed out it helps to separate message
>>semantics from transport (message delivery) aspects.
>>We should keep reliable delivery aspects (such as ACKs,
>>retransmissions,
>>etc.) outside of MIH message semantics.
>>
>>Best Regards,
>>-Vivek
>>
>>> -----Original Message-----
>>> From: stds-802-21@ieee.org [mailto:stds-802-21@ieee.org] On
>>Behalf Of
>>> Srinivas.Sreemanthula@nokia.com
>>> Sent: Friday, February 17, 2006 4:12 PM
>>> To: pbarber@BROADBANDMOBILETECH.COM; STDS-802-21@listserv.ieee.org
>>> Subject: 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
>>> >>>>
>>> >>>
>>> >>
>>> >
>>
>