Re: [802.21] Ad-hoc on ES/CS discussion
My feeling is that;
1. HIM needs a liable connection betwen peers. (agreed)
2. ACK-related mechanism should be designed by MIPSHOP as
one of MIH transport protocol.
3. For retransmission, Timer can be added into MIH function.
Anything else ?
My 0.02 cents.
Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
----- Original Message -----
From: "Gupta, Vivek G" <vivek.g.gupta@INTEL.COM>
To: <STDS-802-21@listserv.ieee.org>
Sent: Tuesday, February 21, 2006 8:57 PM
Subject: 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
>
>