Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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
> 
>