RE: [802.21] AW: [802.21] AW: [802.21] Tomorrow's Telecon material
Hi Kalyan,
Some thoughts inline.
Regards,
Srini
>-----Original Message-----
>From: ext Kalyan Koora [mailto:kalyan.koora@BENQ.COM]
>Sent: Thursday, February 23, 2006 10:54 AM
>To: STDS-802-21@listserv.ieee.org
>Subject: [802.21] AW: [802.21] AW: [802.21] Tomorrow's Telecon material
>
>Hello Subir & Ajoy,
>
>i would just like to clarify my concern on this matter:
>
>- if we are including an optional "ACK" facility in MIHF protocol
> are we covering "ALL" reliability issues?
> For me transporting the packet in time, retransmission ambiguity
> and message integrity (CRC) are also points for reliability.
> If I'm wrong pls. correct me.
Srini> Most IP suite of transport protocols have the checksum support. Also MAC layers do. SO there is no need at MIH layer
>- it is not clear to me yet, what impact is going to come
> on MIHF protocol, if we include ACK as optional:
> + what type of timing issues are to considered between
> sending a MIHF packet and waiting for an ACK (pointed
> out in last teleconf)?
Srini> The timing is left to implementation. For IP transports, it depends on how far the MIHF peer is located. Nominal RTT times for mainlands are within 200ms (within continental US it is under 80ms) and transcontinental RTT times are under 300ms. One could take these values as guidance for simplicity if they do not want to compute their own.
> + whether CRC is to be included into the message at MIHF
> protocol level so that the receiver sends an ACK?
Srini> there is no need
> + what state machines are to be included in the MIHF at
> the sender of a request and also caching of requests
> (though it is an implementation issue, impact is on
> MIHF)?
Srini> this we already discussed. The understanding is that it is left to implementation. No state machines are added for this in the spec.
> + Does MIHF should know in advance about the transport
> protocol prior to deciding about wheter or not to use
> ACK?
Srini> The definition is general and it may be redundant to use MIH ack when peer communicaiton is over L2. So an implementation could take advantage of the knowledge of a certain transport and refrain from using the ACK.
> => if answer to this is yes, then I feel, there is
> a potential to simplify the MIHF protocol further.
> Then it is clear to me that MIHF is the entity which
> is selecting the protocol (Q: on what basis?) So
> we are indirectly inducing some decision mechanism
> into MIHF.
Srini> you mean decision to use mih protocol, which bits to set etc ... Yes. Not decision to select transport since there are other factors there.
> => if answer is no, how does MIHF set this optional
> ACK request?
Srini> We are defining how it does, your question is probably when it does. if an implementation is unaware of transports, then it is the choice of MIHF when/whether to use it.
>May be I missed something in understanding the use of optional
>ACK within MIHF protocol.
>
>Regards,
>Kalyan
>
>-----Ursprüngliche Nachricht-----
>Von: Singh Ajoy-ASINGH1 [mailto:ASINGH1@MOTOROLA.COM]
>Gesendet: Donnerstag, 23. Februar 2006 17:06
>An: STDS-802-21@LISTSERV.IEEE.ORG
>Betreff: Re: [802.21] AW: [802.21] Tomorrow's Telecon material
>
>
>Hi, Subir,
>
>Sorry, due to some conflict, I could not attend today's
>meeting. Btw, I am not sure why we will need to have
>reliability in transport layer if reliability is already
>included as part of MIH protocol. I guess adding reliability
>at two different layers would make the protocol heavy weight.
>However, I do agree that
>we may need to debate this little more before we can conclude
>anything.
>
>Regards,
>Ajoy
>
>-----Original Message-----
>From: Subir Das [mailto:subir@RESEARCH.TELCORDIA.COM]
>Sent: Thursday, February 23, 2006 7:59 AM
>To: STDS-802-21@listserv.ieee.org
>Subject: Re: [802.21] AW: [802.21] Tomorrow's Telecon material
>
>Kalyan,
>We are debating on this issue. Since we are discussing ACK in
>MIH protocol,
>additional reliability requirement may not be necessary. However, we
>need to
>discuss it further.
>
>regards,
>-Subir
>
>
>Kalyan Koora wrote:
>
>>Hi Subir,
>>
>>just a quick comment, reliability is not put as an IS requirement
>>on transport protocol. Is there any reason for this?
>>
>>regards,
>>Kalyan
>>
>>-----Ursprüngliche Nachricht-----
>>Von: Subir Das [mailto:subir@RESEARCH.TELCORDIA.COM]
>>Gesendet: Donnerstag, 23. Februar 2006 02:14
>>An: STDS-802-21@listserv.ieee.org
>>Betreff: [802.21] Tomorrow's Telecon material
>>
>>
>>Pl. find the document for tomorrow's telecon. We will discuss the
>>slides. Also attaching
>>a drafty draft. Folks are working on it. The IETF draft submission
>>deadline is on March 6,
>>9:00 EST. Hopefully we will have a stable version by then.
>>
>>Regards,
>>-Subir
>>
>>
>