RE: [802.21] Ad-hoc on ES/CS discussion
Some comments below.
> -----Original Message-----
> From: Kalyan Koora [mailto:kalyan.koora@benq.com]
> Sent: Tuesday, February 21, 2006 1:25 AM
> To: Gupta, Vivek G; STDS-802-21@listserv.ieee.org
> Subject: 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)
>
[Vivek G Gupta]
Would be preferable to keep MIHF messages independent of both L2/L3 from
transport perspective.
> - 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.
[Vivek G Gupta]
What if the Response gets lost? How about an ACK for a Response?
With this kind of a mechanism/understanding not sure what are you trying
to achieve. If we need to add reliability within MIH protocol then let's
design that appropriately.
>
> - 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.
[Vivek G Gupta]
Confirm is only local within a stack.
>
> - 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 ;-)
>
[Vivek G Gupta]
We need to understand clearly what are the issues we need to
solve/tackle within MIH protocol before just diving into a set of
different solutions.
Best Regards
-Vivek