RE: [802.21] Ad-hoc on ES/CS discussion
> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> Sent: Monday, February 20, 2006 2:42 PM
> To: Gupta, Vivek G
> Cc: STDS-802-21@listserv.ieee.org
> Subject: Re: [802.21] Ad-hoc on ES/CS discussion
>
> > >
> > <clip>
> > >
> > > If the tranport is UDP, ACK is needed at MIHF level.
> > >
> > [Vivek G Gupta]
> > Nope.
> > You probably need some kind of a protocol for reliable transport
here
> > which is outside the scope of MIH message passing.
> > Just one ACK is not gonna solve that problem.
> > What happens if the ACK itself is lost?
>
> In case the ACK itself is lost, the message which requested the ACK
> will be simply retransmitted. Of course we are not going to define a
> full-fledged reliable transport within the MIH protocol.
[Vivek G Gupta]
Why not?
Will it be better to handle this completely within MIH protocol or leave
it completely outside, instead of selectively handling such aspects
within MIH protocol? The question then is what are all the different
transport type aspects that we need to cover within MIH protocol? How
shall we know when we are done?
>
> Even if we consider L2 transport over a new Ethernet type, we would
> face the same problem of "unnecessary retransmission of request that
> has been received but taking time to process" if we don't have ACK in
> the MIH protocol.
[Vivek G Gupta]
I am not saying that you don't need an ACK for such a case. Just that my
impression was that such ACKs need to be handled at the transport level.
For most wireless media at L2 that's already built in. For other cases
where that's not built in, does MIH need to take care of that or shall
that be handled by some other means? If MIH protocol needs to handle
this then we may need to define more than just the ACK
opcode.....retransmissions, timeouts, dealing with duplicate/redundant
packets, etc.
>
> Regards,
> Yoshihiro Ohba
>