Hi Yoshi,
Actually, we didn't discuss ACK message during
yesterday's telecon due to the lack of
time.
By the way, I wonder why we need this ACK
mechanism.
For the request message, the response can be
treated as the corresponding
acknowledgement.
And I think ACK concept is
useful when the transport is not reliable.
Are we(or access technologies) in this
situation?
If yes, I'd like to suggest to use TIMER mechanism
for receiving ACK message as well.
Regards,
Eunah
----- Original Message -----
Sent: Friday, February 17, 2006 5:57
AM
Subject: Re: [802.21] Ad-hoc on ES/CS
discussion
Hi Yoshi,
The intention of the primitive is not over
MIH_SAP or LINK_SAP but only
for internal MIH use. I am okay to extend the
ACK concept to req/resp.
It will be useful in certain scenarios. We can add
the flag for ACK
request in the header. I would like to get other's opinion
on the Opcode
part. I am personally okay with it and modifying the
header.
Regards,
Srini
>-----Original
Message-----
>From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
>Sent: Thursday, February 16, 2006 10:07 AM
>To: Sreemanthula
Srinivas (Nokia-NRC/Dallas)
>Cc: STDS-802-21@LISTSERV.IEEE.ORG
>Subject:
Re: [802.21] Ad-hoc on ES/CS discussion
>
>I have comments on ACK
message.
>
>I agree with defining ACK mechanism. On the
other hand, ACK
>is useful not only for event indication transaction
but also
>request/response transactions.
>
>- ACK does not
have to be defined as a primitive. It can be
>part of general
message handling within MIHF implementation.
>
>- An ACK can be
returned for any request, response and
>indication message as a receipt
of the message.
>
>Having said that, my suggestion
is:
>
>- define a new OpCode for ACK in the MIH fixed
header.
>
>- define a new flag 'a'(cknowledgment required) in the
MIH
>fixed header.
>
>Semantics: If the sender of a
request, response and indication
>message requires an ACK, then it sets
'a' flag in the message.
> If the receiver of a request, response and
indication message
>finds that 'a'
>flag is set, then it returns
an ACK using OpCode=ACK, copying
>the received Transaction ID to the
Transaction ID field and
>with empty payload. The use of ACK is
controlled by within
>each MIHF implementation and transparent to the
MIH users (no
>primitives need to be defined). An ACK MUST NOT be
returned
>in response to an ACK.
>
>If this makes sense, I
can reflect this into my contribution
>on MIH header issue as D05
comment.
>
>What do you think?
>
>Yoshihiro
Ohba
>
>
>
>On Thu, Feb 16, 2006 at 01:14:08AM -0600,
Srinivas Sreemanthula wrote:
>> Hello,
>> Here is the
document from previous discussions. I have made some
>>
changes
>> (highlighted) based on the ongoing email discussions. I
encourage to
>> discuss the relevant hot button issues and arrive to
a conclusion.
>>
>> Regards,
>>
Srini
>>
>>
>>
________________________________
>>
>> From: ext Srinivas
Sreemanthula
>> [mailto:Srinivas.Sreemanthula@nokia.com]
>>
Sent: Wednesday, February 15, 2006 5:27 PM
>> To: STDS-802-21@listserv.ieee.org
>>
Subject: [802.21] Ad-hoc on ES/CS discussion
>>
>>
>> Hello participants,
>> Here is the adhoc telecon
information for tomorrow
>(2/16) regarding
>> ES/CS
information. Primarily the discussion is related to
>registration
>> and related aspects like MIH ID, session ID etc. If time permits,
we
>> could include the ACK discussion.
>>
>>
Regards,
>> Srini
>>
>> Name of the conference:
IEEE 802.21 ES/CS Discussions
>>
>> Time: 8-10am
CT
>>
>> Conference ID: 59489, PIN: 110483
>>
>> US Phone Number: 972-894-6500
>>
>> EU Phone
Number: +358 7180 71870
>>
>> Type of reservation: Single
reservation: 16.02.2006
>>
>> (GMT-06:00) Central Time (US
& Canada)
>>
>> Number of participants: 20
>>
>> Instructions language: English
>>
>> Features:
participant's identification
>>
>
>
>
|