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



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