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
>> >>>>
>> >>>
>> >>
>> >
>