AW: [802.21] AW: [802.21] Ad-hoc on ES/CS discussion
Hi Srini,
in the initial discussion, it was said that "depending" on the
selection of transport protocol, this bit is set. That is the
reason, I mentioned this.
Anyhow, as we discussed now, you can also include me on the list.
Regards,
Kalyan
-----Ursprüngliche Nachricht-----
Von: Srinivas.Sreemanthula@nokia.com [mailto:Srinivas.Sreemanthula@nokia.com]
Gesendet: Dienstag, 21. Februar 2006 17:33
An: Kalyan Koora; STDS-802-21@listserv.ieee.org
Betreff: RE: [802.21] AW: [802.21] Ad-hoc on ES/CS discussion
Hi Kalyan,
I agree with you that MIH must be transport independent. 'a' bit is one
way to indiate that the source requires an ACK in the reverse direction.
This mechanism essentially allows us to keep ACK optional. Are you
proposing that it can be made mandatory and not have 'a' bit?
Regards,
-Srini
>-----Original Message-----
>From: ext Kalyan Koora [mailto:kalyan.koora@BENQ.COM]
>Sent: Tuesday, February 21, 2006 3:25 AM
>To: STDS-802-21@listserv.ieee.org
>Subject: [802.21] 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
>>
>