AW: [802.21] Ad-hoc on ES/CS discussion
Hello together,
I was a bit surprised to see all the emails regarding ACK :-)
So, I would also like to join this heavy discussion and add
my thoughts to it ;-)
- At first we are "trying" to desing MIHF protocol to be
independent of transport protocol. Thus, I would say, we
should treat L2 and L3 as one (at least from .21 point of view)
- We are also aiming in the desing that MIH is not having the
knowledge over which transport protocol its packets are sent.
If we say, it has this knowledge, then we should mention it
in our draft to avoid all these misunderstandings. And this
will also solve many other points.
- If we feel, that the relaibility is a point for transport
protocol, then we "SHOULD" put it as a requirement for transport
protocol (I think this is agreed in some cases).
- In most of the cases we have Request and Response to the
request. So, for me Respone is some sort of ACK that the
message is delivered.
- In some of the cases we have Request and confirm to the
request. So, for me confirm is some sort of ACK that the
message is delivered.
- I see only for "indication" we do not have any response.
I fell the concern from Srini and Yoshi is comming from
these primitives. So here are my proposals to solve this:
o also add a "confirm" or "response" primitive to these messages,
eg. Link_Up.Indication and Link_Up.Confirm
By the way, we have Request, Response and Indication
defined as OpCodes, but not Confirm.
o add a new OpCode as suggested "ACK" to these messages
without any time lines and other specific parameters.
o add a new ACK-TLV, which can be used for this purpose.
(This include some overhead compared to the ACK or confirm
or response OpCodes, therefore, I prefer the other
solutions rather than this)
=> This would avoid us from keeping the MIH to know about
the transport protocols
=> This would avoid us from using the "a" bit
=> This would also include some sort of "Relaibility" to
the MIHF protocol (all the messages do have some sort
of ACK)
I'm eager to see the reactions from your side ;-)
regards,
Kalyan
> -----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
>