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