Subject: Re: Extensions to CRTP

From: GeeVarghese John <[email-masked]>
Date: Wed, 01 Dec 1999 17:10:17 -0500

Tmima, team and Lars (and all u there in the rem list)

At this point one thing came to mind I am just presenting here
Could you please commnet on this ..

Apart from F_HDR, C_RTP & C_UDP packet
if we can have C_UDP with IP id transmitted as it is in the IP/UDP/RTP
packet ..
we may have the following advantages ..

1) Avoiding negative cache :
Compression can be at 3 stage  first start compressing a flow  with
CRTP at this state  when this state when the flow is detected as too
much inconsistent,
compression state can be moved to C_UDP if still inconsistent move to
C_UDP with
IP id send as it is (Say C_UDPi) packet.
For the inconsistent flow C_UDPi state is the last state and   can avoid
moving
to negative cache ..Advantage of this mechanism is

2) We use heuristics to find RTP flow ..
Even if the flow identified is not RTP which can be started with
C_RTPcomperssion and
if the flow is found to be too much inconsistent  move to the
sucsseeding states.
Still we get a compression benifit .

3) It is the experiance that CRTP is more processor intensive ..
When there has to be a balance, C_UDPi packet sending need not be that
processor intensive
and can improve the throughput. Because here the delta encoding is less
..
So compressor can decide on whether to send only C_UDPi packet for
particular flows
or all flows.

4) "Extension to CRTP" draft talks on running CRTP algo over ATM links,
In that case ..
Is the sequence number space 1-16 sufficient ?
C_UDPi packet need not be sequentially aligned .. So we can avoid
looking at the sequence number.

Compression rate will be as follows

C_RTP -> 2 (or 4 ) bytes from 40 bytes
C_UDP-> 2 (or 4) from 28
C_UDPi -> 4 or (6) from 28 but there will not encoding.

I feel tmima's change to the draft should be to indicate an explicit IP
id value ..
and if people agree on these points you may append these points .
Yes, In my previous mail I suggested as having one bit to indicate
deltaT and IP id.

Please comment ....

Rgds
GVJ

GeeVarghese John wrote:

> Tmima,
>
> Thanks for the reply and I have added some more comments on the CU+
> packets in this
> mail. I read the first mail from "Lars-Erik Jonsson", and your reply
> to that, Good
> you are changing the CU+ with IP ID but you may not need to set M bit
> there,
> by settting deltaT bit you can encode both deltaT and IP ID, because
> you need both values...
> I have added whatever comments I have about CU+,  please read that
> below
> According to me CU+ with IP ID also will not give a robust solution.
> Reason stated below.
>
> I think we should windup our discussion on CU + with this mail unless
> someone else is
> interested. If you want to reply to me please ..If you want more
> clarrification on my point
> I will reply back.
>
> My next mail will address few things about ACCEPT/REJECT
> packet use, you & team proposed. Please reply to that mail.
>
> My comments on CU+ are :
>
> Point 1.1:
>
> IP ID can be assigned by an host in three ways
> a) sequence number in ascending order with variace 1
> b) random number
> c) sequence number with variance n (n >1)
>
> I am not aware of any other implementation ..(May be possible)
> IF the IP id variance is not in the ascending order,
> CU+ will have problem. You expect that, host will implement this
> while transmitting the RTP packets. I dont know how many (non
> compliant) people
> will change this for the new proposal came in "extending CRTP".
> Or you are agreed for IP ID in CU+, it is a positive move.
>
> Point # 1.2
>
> Infact looking at the sequence number of CUDP packets helps to  get
> rid of
> IP id sync problem which we discussed .  (What I meant is if CUDP came
> in with a
> non expected link seqnumber, decompressor send out a CS packet to
> compressor to synchronise the context)
> This will take care all issues with the IP id variance (variance in
> any manner random, ascending order).
> If we extend CRTP with the new extension you proposed,
> we may loose this synchronization chance between compressor and
> decompressor,
> because we are NOT expected to look at CUDP+ (or CU+) link sequence
> number
> to synchronize anymore as far as IP ID variance is concerned.
> Otherwise CU+ packet should always carry IP ID field then we can avoid
>
> looking at sequnce number but not in the case with CU packet.
>
> What is your comment about CUDP with extension co-exist?
> Should it look for link seq number match further also  ?
>
> Point #2
>
> One solution to IP ID prolem you stated as "Twics Algo"
> Solution to this problem could be using twice algorithm.
> But "twice" algorithm is not mandatory. There are implementations
> without preserving UDP checksum. In this case I dont have an answer.
> May be we have to force a standard that everyone should implement
> UDP checksum while transmitting out. I dont know how many people will
> do that.
>
> Point #3.1
>
> In our discussion we have addressed two kinds of packet loss
>
> 1)  RTP packet loss in the network before reaching compessor (Say L1)
> 2) Compressed packet loss sent from compressor to decompressor (Say
> L2)
>
>
> In a lossy environment (L1), we end up in sending more number of
> encoded bytes
> with CU+ than what we used to send with CR+.
> Because in CU+ we encode deltaT of the next expected RTP packet, with
> the current packet.
> I can understand your point that source generate with same periodic
> time gap for
> each packet within a talkburst. But the carrier network is IP datagram
> service and
> (+ link lossy nature). So should we rely on the possible network
> behaviour or should we, on the source behaviour.
>
> If L2 is greater than L1 then you claimed advantage of CU+ sync
> between compressor
> and decompressor can be achieved.
>
> But What is the likely chance for L2 >  L1 ?
> Only for some specific lossy links.
>
> Point # 3.2
>
> As far as I know CRTP use some heuristic mechanism to identify a RTP
> flow.
> It is not a definite mechanism. In this case  does it make sense to
> send the deltaT of the next expected packet. Consider L1 case
> mentioned above.
> Not only that, assume the time gap between talkburst is (T1) and time
> gap between
> inter packet arrival of same session is T2. Consider a case of,
> If we have identified a non-RTP flow as RTP flow and started
> compression
> with our heuristics how do we determine when to send CU+.
> Will we end up in sending continuous CU+ ?  we may ..
> There need not be talkburst gap with some what high definite gap
> when  compare to interpacket gap of the same session...
> (See Pt # 4 on CU+ size comparison with CR+)
>
>
> Point #4
>
> Size of the CU+ is more than CR+ because of the compressed RTP header
> ..
> in CR+. In CU+ you send complete RTP header as it is (i.e 12 byts).
> In old CRTP, Assume that for some situation we have to encode RTP seq
> number and
> Timestamp, For ideal case encoded byte size will be 2 byts (1 for seq
> number
> + 1 for deltaT) or otherwise 4 or max 6 (still less than 12 bytes).
> Over a lossy link (L2), which is particular to the link, advantage of
> CU+ is missing.
>
> Continuous sending of CU+ for a talk burst may avoid send CS from
> decompressor to
> compressor. But What kind of loss is more likey L1 or L2.
>
>
> My personal comment to CU+ is
>
> May be we can claim some advantage only if
> the stated assumptions (about packet loss (L1 < L2),  twice algo..etc)
> are met ..
> That also with the modification of IP ID inside the CU+  packet.
>
> Thanks & Rgds
>
> GVJ
>
> Tmima Koren wrote:
>
>>  At 10:17 PM 11/23/99 -0500, GeeVarghese John wrote:
>>
>> >
>> >
>> >> >> >
>> >> >> > The decompressor will stay in sync as long as he received at
>> >> >> > least one of the CU+
>> >> >>
>> >> > I think any of the CU+ loss will lead to CONTEXT_STATE packet
>> >> > generation from
>> >> > decompressor to compressor because of the link seq number
>> >> > mismatch ..Is nt it ?
>> >>
>> >>  The decompressor should be in sync after receiving a CU+. There
>> >>  is no reason for a CS
>> >>  Tmima
>> >
>> > Tmima,
>> >
>> > Could you please explain, how IP id variance should be treated in
>> > this case ?
>> > For IP id field  first order difference is sent as delta in CUDP
>> > with I bit set.
>> > In this case, if there is a CU+ packet loss how IP ID delta
>> > encoding should be treated ..
>>
>>
>> Usually the IP id will not increment uniformly in packets of an RTP
>> stream (the host sends packets other then the RTP streams, silence
>> periods).
>> This means that if we want to compress a stream, we might have to
>> send a new deltaID often, maybe in each packet. This will increase
>> the size of the packets.
>> To optimize the compression, the host can assign IP id's to the
>> packets of each stream in a constant increment.
>> This keeps the deltaID constant for each stream.
>>
>> The advantage of a CU+ packet is that in one packet we restore all
>> RTP-related parameters at the decompressor.
>> The sequence of:  CU followed by a CR+  is very vulnerable: the CU
>> zeroes the deltaT, so if the CR+ was lost, the decompressor is out
>> of sync.
>> The CU+ does not restore the IP id. But if the implementation keeps
>> the deltaID constant..
>>
>> After a silence period, the sequence number will still increment by
>> 1 and the IP id by deltaID: there is no reason to skip RTP sequence
>> numbers or IP id's. deltaT is the only difference that is not
>> correct for the first packet after a silence period.
>>
>> To optimize CRTP over lossy links
>> 1. Use a constant deltaID
>> 2. Check udp checksum
>> 3. Use CU+ as necessary
>>
>>
>>
>> > and also I am not still convinced with the advantage of CU+ over
>> > CR+ after
>> > the  silence period. Could you please explain your point  ..(please
>> > ref my previous mail)
>>
>>
>> Let's say that the characteristics of the link is that we may lose
>> at most 1 packet in a row
>> If we use:
>>
>> 11      200       CR+    dt=100
>> 12      210       CR+    dt=10
>> 13      220       CR
>>
>> If 11 is lost, the decompressor does not have the correct RTP
>> timestamp for packet 12.
>> If 12 is lost, the decompressor has a wrong deltaT.
>> In both cases the decompressor is out of sync.
>> This is a very weak sequence to use after a silence period.
>>
>> If instead we use:
>>
>> 11"    200       CU+    dt=10
>> 12"    210       CU+    dt=10
>> 13"    220       CR
>>
>> In this case If one of 11" or 12" is lost, the decompressor remains
>> in sync. So this is a very strong sequence
>>
>> Tmima
>>
>>
>>
>> > Please reply .
>> >
>> > Rgds
>> >
>> > GVJ
>>
> -

---

From: Tmima Koren <[email-masked]>
Date: Wed, 01 Dec 1999 11:33:40 -0800

When the IP ID is changing arbitrarily, we have to change the deltaID very frequently - probably in every packet.
In such cases it might be more useful to include the full IP ID in a CR instead of the deltaID.
This can be done if we could change the meaning of the 'I' flag in the CR packet to mean either full IP ID or deltaID.
Maybe we can add an option to the CRTP negotiation about the usage of the 'I' flag in CR: full IP ID or deltaID
Then if a host requires preserving the IP ID and cannot assign them sequentially for the compressed RTP streams, the host will negotiate the 'I' flag in CR packets to mean full IP ID.
Or if we want this to be per stream, add a flag in the FH.

Are there cases when it's ok for the CRTP compressor to reasign the IP ID?

Tmima

---

From: GeeVarghese John <[email-masked]>
Date: Thu, 02 Dec 1999 19:39:10 -0500

Hi,

> In such cases it might be more useful to include the full IP ID in a CR instead of the deltaID.

Exactly, you are correct ..
This is the thing I was mentioning by saying three stages of compression.
At the first stage we can start compressing a flow at CRTP then if we found the flow is
inconsistent then move the state to CUDP and send only CUDP packet then CUDPid packet.
Inconsistency can be interms of anything ..
One thing could be like what you said about IP id variance rate or other delta encoding rate or CONTEX_STATE packet received etc ..

> Or if we want this to be per stream, add a flag in the FH.

It looks Very good. I am in favour of  negotation  at CRTP level not only for this point
I have something more on seq number extension also. May be later we will discuss this.
But Adding the information bit in the FH packet how do we ensure the reliable
delivery of the FH packet ..If Accept and Reject packet is the soln in your mind
That could be one possibility but Accept and Reject packet will have many other dsadvantes.
Instead of that, why cant we have a protocol negotiation packet which needs to be sent
only one time when the stack is initialised. For this packet we can have a design where
negotation parameters can be exteneded so that future requirement also will be taken care.

> Are there cases when it's ok for the CRTP compressor to reasign the IP ID?

Do you mean that CRTP will reassign a new IP id to the decompressed IP packet  ..?

Rgds
GeevJohn
--
-------------------------------------------------------------------------------
[ ]  Motorola Confidential Proprietory
[ ]  Motorola Internal Use Only
[x]  Not an MCP or MIU
-------------------------------------------------------------------------------
Geevarghese John,
DataCom Group,
Motorola India Electronics Ltd,
"The Senate", No-33 A,
Ulsoor Road,
Bangalore - 42.
Phone  : 91-80-5598615  Xnt-4005
E-mail : [email-masked]
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------

---

From: Tmima Koren <[email-masked]>
Date: Fri, 03 Dec 1999 14:13:20 -0800

At 07:39 PM 12/2/99 -0500, GeeVarghese John wrote:
>One thing could be like what you said about IP id variance rate or other 
>delta encoding rate or CONTEX_STATE packet received etc ..

Yes. This is the same idea.
The CRid can be used when the RTP parameters are consistent, but the IP ID is not.

Mikael Degermark suggested to enhance the COMPRESSED_NON_TCP packet instead of the CUDP 
The COMPRESSED_NON_TCP packet includes the IP ID, the udp checksum (if nonzero) and also includes one byte of data which currently holds the 4-bit CRTP sequence# (see rfc2507). 2 of the 4 unused bits can be used to flag 'T' and 'I', so the packet may also include the deltaT and deltaID if necessary.
Such a packet will restore all parameters at the decompressor, same as CUDPid

>
>>
>> This can be done if we could change the meaning of the 'I' flag in the CR 
>packet to mean either full IP ID or deltaID.
>> Then if a host requires preserving the IP ID and cannot assign them 
>sequentially for the compressed RTP streams, the host will negotiate the 'I' 
>flag in CR packets to mean full IP ID.

I meant adding options to the IP header compression negotiation as described in rfc2509

>Do you mean that CRTP will reassign a new IP id to the decompressed IP 

Yes. I suggest a mode where CRTP does not preserve the IP ID.
Tmima

---

From: Mikael Degermark <[email-masked]>
Date: Sun, 05 Dec 1999 18:39:14 +0100

I feel that I have to inform you people that when we were pushing 2507 and
2508 to
Proposed Standard, we originally proposed not to maintain the IP ID. The IESG
would not agree to that due to potential problems and we had to back off. 

Before going too far along the path of not maintaining the IP ID, I would
recommend
sounding out the IESG to see if they changed their minds. 

Mikael Degermark

At 02:13 PM 99/12/03 -0800, Tmima Koren wrote:
>>> When the IP ID is changing arbitrarily, we have to change the deltaID
very 
>>frequently - probably in every packet.
>The COMPRESSED_NON_TCP packet includes the IP ID, the udp checksum (if
nonzero) and also includes one byte of data which currently holds the 4-bit
CRTP sequence# (see rfc2507). 2 of the 4 unused bits can be used to flag
'T' and 'I', so the packet may also include the deltaT and deltaID if
necessary.

---

From: GeeVarghese John <[email-masked]>
Date: Tue, 07 Dec 1999 22:42:31 -0500

> Such a packet will restore all parameters at the decompressor, same as CUDPid

What I read about COMPRESSED_NON_TCP packet is, it is optional for CRTP and
mainly meant for fragmented packet etc ..Are we nt restricting the advantages here ..
(CUDP with IP ID can compress more (UDP etc ) fields than NON_TCP packet)
But having a mechanis to send IP ID will definitely give some sort of improvement in CUDP.

--

---

From: GeeVarghese John <[email-masked]>
Date: Tue, 07 Dec 1999 22:45:26 -0500

Tmima,

I wanted to ask you some doubts on ACCEPT/REJECT packet in CRTP
extension draft..
It is a continuation of the old mail. In you answer below, though you
wrote the
ACCPET/REJECT packe is optional, I think definition of these packet are
bit confusing.
First of all I feel no need of a ACCEPT packet
Second Why to have a REJECT packet as separate packet to invalidate the
context ..
Why cant we use CONTEXT_STATE packet for the same ..
We can have a bit in CS packet  indicating that context need to be
invalidated or
resynchronised using FH packet. If there is no CS packet it is assumed
that
flow ACCEPT.

Here the issue of interoperability also arise when an implementation
interopeate with the
old CRTP (2508) implemnetation new implemetation expected ACCEPT or
REJECT packet
for each FH packet .. If it does not receive either packet what action
compressor is expected to take. To make interoperation possible there is
a need for some sort of negotiation, here also a protocol level
negotiation is expected ..
So I feel the approach with ACCEPT/REJECT packet is not optimal.
But the solution I suggested  does not cause any interoptation issue
also.
No extra packet overhead, no protocol modification etc  ...

Could please answer your points on this ..

Thanks & Rgds

GVJ

>
>
>> Q3) Section III : Acknowledgement to a new compressed stream
>>
>> Context Invalidation was one point which I had pointed out to
>> Steve/tmima long time back ..
>> I am having those mails with me ..
>>
>> But, (i) Do we need ACCEPT and REJECT packet  ??
>> Having a NACK mechnism sounds reasonable ..
>> I feel there shouldnt be both ..
>> But what compressor is supposed to do after sending the first
>> FULL_HEADER packet
>> when compressor waiting for the ACCEPT or REJECT
>> should it queue the packets till the reply/or timeout
>> or Should it send the compressed packets assuming the decompressor
>> will drop if there are
>> REJECT state at the decompressor side.
>>
>> But (ii) what about the backword compatibility issue because this
>> ACCEPT/REJECT mechanism has dependancy and it will not work with
>> CRTP-2508
>>
>> As per the current proposal we need to send ACCEPT/REJECT packet for
>> every
>> FULL_HEADER packet ... (iii)Is it not adding extra bandwidth
>> consuption ..
>> Draft talks about FULL_HEADER retransmit as well ..
>
>
> The REJECT packet is useful when the decompressor runs out of
> resources. The compressor initiates compression of a stream by sending
> a FH. With CRTP today the decompressor can send a CS to invalidate the
> context, but the compressor does not know the reason and will attempt
> to compress this stream again. A REJECT will notify the compressor
> that the decompressor cannot handle compresstion of additional streams
> at this moment.
> An implementation that was not enhanced to use REJECT will still use
> CS to invalidate the context each time the compressor attempts to
> compress the stream.
> The compressor continues to send the compressed packets of the stream
> until he receives CS or REJECT
> The intent is to make the ACCEPT/REJECT packet optional - an
> optimization.
>
> Tmima
>

---

From: Mikael Degermark <[email-masked]>
Date: Tue, 07 Dec 1999 20:21:38 +0100

>mainly meant for fragmented packet etc.

CNTCP can be used for any header. It does not use delta-encoding. For a
UDP/IP header,
the difference from CUDP is that the IP identifier is not sent using delta
encoding. Instead,
it is sent as an absolute value. It is not true that CUDP compresses more
fields than 
CNTCP (except for IP ID of course). What fields did you have in mind?

> ..Are we nt restricting the advantages here ..

The real question here is whether one wants to have more than one way to do
things.
If one decides to go with CUDP with the option of sending the IP ID as-is,
there will 
be two ways. Moreover, when we want to support IPv6, where there is no IP
ID field,
CUDP becomes more or less obsolete.

>> >packet to mean either full IP ID or deltaID.

The case where the IP ID increments as expected would then not be covered.
That would be bad for the well-behaved stack which increments IP ID by one
for each packet. 

>> >> Maybe we can add an option to the CRTP negotiation about the usage of
the
>> >'I' flag in CR: full IP ID or deltaID

Won't work when the host is on the receiving end of the RTP stream.

>> >> Or if we want this to be per stream, add a flag in the FH.

Negotiating on that level will add considerably to the complexity of the
protocol
in the presence of dropped packets, etc. 
Do we really want that?

>> I meant adding options to the IP header compression negotiation as
described in rfc2509

Please make sure that what you propose makes sense for the case where none
of the endpoints of the narrow link is the sender. It does not seem to me
that the 
information needed to negotiate for example the meaning of the 'I' bit is
necessarily
available to either side of the link. 

>> Yes. I suggest a mode where CRTP does not preserve the IP ID.

Please make sure that the IESG has changed their mind before you pursue that
any further. Might save you some work & trouble. 

Micke Degermark

---

From: Tmima Koren <[email-masked]>
Date: Tue, 07 Dec 1999 12:21:21 -0800

At 10:45 PM 12/7/99 -0500, GeeVarghese John wrote: 
>
> Tmima, 
>
> I wanted to ask you some doubts on ACCEPT/REJECT packet in CRTP extension
> draft.. 
> It is a continuation of the old mail. In you answer below, though you wrote
> the 
> ACCPET/REJECT packe is optional, I think definition of these packet are bit
> confusing. 
> resynchronised using FH packet. If there is no CS packet it is assumed that 
> flow ACCEPT. 

Yes, we suggested two formats for the REJECT packet: one is using a new code,
and the other is using the CS with an extra bit
See attached presentation (presented in DC)
We also prefer to use the 'CS + extra bit' format 
Tmima

> old CRTP (2508) implemnetation new implemetation expected ACCEPT or REJECT
> packet 
> compressor is expected to take. To make interoperation possible there is a
> need for some sort of negotiation, here also a protocol level negotiation is
> expected .. 
> But the solution I suggested  does not cause any interoptation issue also. 

All the enhancements are not backward compatible so we'll have to change the
negotiation: maybe negotiate a version of CRTP, or negotiate the new options
separately
Tmima

>>> Context Invalidation was one point which I had pointed out to Steve/tmima
>>> long time back .. 
>>> But what compressor is supposed to do after sending the first FULL_HEADER
>>> packet 
>>> or Should it send the compressed packets assuming the decompressor will
>>> drop if there are 
>>> ACCEPT/REJECT mechanism has dependancy and it will not work with CRTP-2508 
>>>
>>> As per the current proposal we need to send ACCEPT/REJECT packet for every 
>>> FULL_HEADER packet ... (iii)Is it not adding extra bandwidth consuption .. 
>> The REJECT packet is useful when the decompressor runs out of resources. The
>> compressor initiates compression of a stream by sending a FH. With CRTP
>> today the decompressor can send a CS to invalidate the context, but the
>> compressor does not know the reason and will attempt to compress this stream
>> again. A REJECT will notify the compressor that the decompressor cannot
>> handle compresstion of additional streams at this moment. 
>> An implementation that was not enhanced to use REJECT will still use CS to
>> invalidate the context each time the compressor attempts to compress the
>> stream. 
>> The compressor continues to send the compressed packets of the stream until
>> he receives CS or REJECT 
>> The intent is to make the ACCEPT/REJECT packet optional - an optimization. 
>>
>> Tmima 
>>  
>

---

From: GeeVarghese John <[email-masked]>
Date: Wed, 08 Dec 1999 17:35:24 -0500

Tmima,

It is a good news for me that you added the bit solution in CS packet
for contex invalidation.
I remeber on 15 April 1999 when I pointed out this problem and this soln
to Steven Casener
the response I got from him was not in favour of this idea. He just
replied ::
>>> you can't just have an error flag.
May be I didnot communicate properly.
Anyway this solution is in place though the ownership is for different
people, No problem.

Could you please send me the latest draft ...

Thanks & Rgds
GVJ

Tmima Koren wrote:

>> It is a continuation of the old mail. In you answer below, though
>> you wrote the
>> ACCPET/REJECT packe is optional, I think definition of these packet
>> are bit confusing.
>> Second Why to have a REJECT packet as separate packet to invalidate
>> the context ..
> Yes, we suggested two formats for the REJECT packet: one is using a
> new code, and the other is using the CS with an extra bit
>> for each FH packet .. If it does not receive either packet what
>> action compressor is expected to take. To make interoperation
>> possible there is a need for some sort of negotiation, here also a
>> protocol level negotiation is expected ..
> All the enhancements are not backward compatible so we'll have to
> change the negotiation: maybe negotiate a version of CRTP, or
> negotiate the new options separately
> Tmima
>
>
>
>> Thanks & Rgds
>>
>> GVJ
>>
>> >
>> >
>> >>  or Should it send the compressed packets assuming the
>> >>  decompressor will drop if there are
>> > resources. The compressor initiates compression of a stream by
>> > sending a FH. With CRTP today the decompressor can send a CS to
>> > invalidate the context, but the compressor does not know the reason
>> > and will attempt to compress this stream again. A REJECT will
>> > notify the compressor that the decompressor cannot handle
>> > compresstion of additional streams at this moment.
>> > An implementation that was not enhanced to use REJECT will still
>> > use CS to invalidate the context each time the compressor attempts
>> > to compress the stream.
>> > The compressor continues to send the compressed packets of the
>> > stream until he receives CS or REJECT

Geevarghese John,
DataCom Group,