RE: [802.21] Ad-hoc on ES/CS discussion
Eric,
Some comments below.
> -----Original Message-----
> From: NJEDJOU Eric RD-RESA-REN [mailto:eric.njedjou@francetelecom.com]
> Sent: Wednesday, February 22, 2006 12:38 AM
> To: Gupta, Vivek G; Kalyan Koora; STDS-802-21@listserv.ieee.org
> Subject: RE: [802.21] Ad-hoc on ES/CS discussion
>
>
> >-[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
>
> Hi Vivek and all,
>
> Agree with the previous point that we need to better understand the
> issues we need to solve on route to designing the MIH protocol. But i
am
> stunned by this discussion.
> Robustness/state machine we want of such a protocol as MIH is
completely
> separated from the transport protocol reliability be it at L2 or L3.
> Just look at MIP: whenever a host informs its home agent that it would
> like to bind its home adress to an alternative care-of-adress, it
waits
> until it receives the corresponding ACK from the home agent before
> actually using that new care-of-adress to start sending packets again.
> And that behavior is needed irrespective of wich transport one might
> ever want to carry the MIP signalling with. It turns out that UDP is
> used as the transport for MIP and one might argue that that was the
> reason to ack the binding update. Designers of MIP might bring
> contradictions but my conviction is that the reason was not there at
> all.
[Vivek G Gupta]
There is a difference between sending an ACK as a status of executing a
command/request/action and sending an ACK when you have just received
the packet. In case of MIHF protocol, the status of executing command
Requests is returned in Response messages. There is no status returned
for event indications. In telecon this morning it was understood that
the ACK was required for all messages, so in that sense this ACK turns
out to be mostly for reliability of transport.
>
> The same applies in our case. Some deployments scenarios would for
> example want the station to ACK the reception of an MIH switch command
> so that appropriate action (for example re-routing of IP traffic to
the
> new link) is started by a mobility anchor in the network. And
> reliability of the used transport won't provide any useful information
> to that mobility anchor that the switch command was received and
> treated. Note that a transport can be reliable and still for any
reason
> the host is not able to properly process the request (something got
> wrong for example on local stack). Sending an ACK usually serves the
> purpose of telling the peer that everything happened as planned upon
> reception of the command.
[Vivek G Gupta]
Seems like an appropriate Response type message in which you can
communicate the status of executing the command. And for every Request
we do have a Response in our draft.
>
> To some up, let's not divert ourselves with transport issues too much.
> That's not really much of the problem here!
> Let's rather evaluate the necessity for a peer node to receive an ACK
on
> an action requested by that node on a pure protocol conception basis.
>
[Vivek G Gupta]
I agree. In some sense that's precisely what some of us were trying to
determine.
> Best Regards
> Eric