Subject: [rohc] SigComp packet sniffer

From: "Ravi S" <[email-masked]>
Date: Mon, 19 Nov 2007 18:52:44 +0530

I want to implement a packet sniffer for decompressing sigcomp messages
(Just like wireshark but only for sigcomp messages).  The diagram below
shows where the packet sniffer fits in the network.

   +------------+         +------------+         +------------+
   |  SigComp   |---(c)-->|   SigComp  |---(c)-->|  SigComp   |
   | Endpoint A |         |   Packet   |         | Endpoint B |
   |            |<--(c)---|   Sniffer  |<--(c)---|            |
   +------------+         +------------+         +------------+
                                |
                                v
                        Decompressed packet

Since the packet sniffer only decompresses the packet, it need to implement
only UDVM and state handler.  It is enough to commit all the states (from
different endpoints) in to a same compartment.  Is this correct?

Now my question is can the packet sniffer generate NACK message if
decompression failure occurs? What performance impact does it have on sigcomp
endpoints?

-- 
Coming Soon: Signature 2.0 (Beta)

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: [email-masked]
Date: Mon, 19 Nov 2007 19:04:54 +0530

Hi Ravi S,

Sniffer need to maintain separate compartments for following some reasons

  1) To Manage the state memory compartment wise (i.e. because you cannot 
store the states unlimitedly) 
  2) to store SigComp parameters compartment -wise 

i,e sniffer has to maintain two compartments for every compartment mapping 
between (A-B) . 

I didn't understand why sniffer has to generate NACK..? anyway packet 
sniffer cannot generate NACK message because for some error codes NACK 
generator has to provide error details in the NACK message. sniffer may 
not have these details.

Please let me know your views.

Best Regards,
Ranjith Reddy. V
Sr. Software Engineer
Aricent-Bangalore.

Effortlessness is born out of great effort.

"Ravi S" <[email-masked]> 
11/19/2007 06:52 PM

To
[email-masked]
cc

Subject
[rohc] SigComp packet sniffer

Since the packet sniffer only decompresses the packet, it need to 
implement
only UDVM and state handler.  It is enough to commit all the states (from
different endpoints) in to a same compartment.  Is this correct?

Now my question is can the packet sniffer generate NACK message if
decompression failure occurs? What performance impact does it have on 
sigcomp
endpoints?

***********************  Aricent-Unclassified   ***********************
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of 
the individual to whom it is addressed. It may contain privileged or confidential information and should not be 
circulated or used for any purpose other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for 
loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Ravi S" <[email-masked]>
Date: Mon, 19 Nov 2007 20:06:59 +0530

Thanks Ranjith for the reply.  As you said the sniffer cannot store
states unlimitedly.  Probably i can have a very big limit.  But since
the sniffer is not going to do compression, saving it per compartment
is nor required.  Please correct me if I am wrong.

On Nov 19, 2007 7:04 PM,  <[email-masked]> wrote:
> generator has to provide error details in the NACK message. sniffer may not
> have these details.
>
> To [email-masked]
> Subject [rohc] SigComp packet sniffer
>
>
>
>
>
>
> the individual to whom it is addressed. It may contain privileged or
> confidential information and should not be
> please notify the originator immediately. If you are not the intended
> recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the contents of this
> message. Aricent accepts no responsibility for

---

From: [email-masked]
Date: Mon, 19 Nov 2007 20:46:07 +0530

Hi Ravi,

What will be the maximum limit ..? 

Assuming maximum limit is very high, what is the mechanism to  delete  a 
particular STATE if  no of states reached to maximum limit.

Decompression failure occurs if you delete an useful state. 

If you consider retention priority and FIFO mechanisms while deleting a 
state there is a chance of deleting useful state because states are not 
maintained compartment specific. (This chance will be very high in load 
conditions) 

Best Regards,
Ranjith Reddy. V
Sr. Software Engineer
Aricent-Bangalore.

"Ravi S" <[email-masked]> 
Sent by: [email-masked]
11/19/2007 08:06 PM

To
Ranjith Reddy V/BLR/HSS@HSS
cc
[email-masked]
Subject
Re: [rohc] SigComp packet sniffer

> generator has to provide error details in the NACK message. sniffer may 
not
implement
> "DISCLAIMER: This message is proprietary to Aricent and is intended 
solely
> for the use of
> circulated or used for any purpose other than for what it is intended. 
If
> you have received this message in error,
> loss or damage arising from the use of the information transmitted by 
this
> email including damage from virus."
>
>

---

From: "Ravi S" <[email-masked]>
Date: Tue, 20 Nov 2007 16:18:09 +0530

Thanks Ranjith for the reply.  Is there any good proposal you have for
sigcomp packet sniffer?  All I want to do is watch all the sigcomp
packets going through the network.

I am interested in things like states going out of sync between the
sigcomp endpoint and sniffer.  As you mentioned if NACK cannot be
generated at sniffer there is no way a sniffer could watch the packets
once it gets decompression failure.

Thanks in advance!

On Nov 19, 2007 8:46 PM,  <[email-masked]> wrote:
> To Ranjith Reddy V/BLR/HSS@HSS
>
> cc [email-masked]
>
> Subject Re: [rohc] SigComp packet sniffer
>
>
>
>
>
>

---

From: "Ravi S" <[email-masked]>
Date: Thu, 22 Nov 2007 16:13:02 +0530

Thanks, Ranjith! As you mentioned generating NACK at sniffer is not a
good idea.  But the sniffer should have the view of all the states
from both the endpoint.

To ensure that, if SMS size of sniffer is greater than both the
endpoints will it be enough?

On Nov 20, 2007 4:29 PM,  <[email-masked]> wrote:
>
> Hi Ravi,
>
> I do not have any proposal of that kind.
>
> If sniffer generates unnecessary NACK it MAY effect the SigComp
> functionality of the original end (A or B).
>
> basically  A will have a view of states at B end (vice versa) , the same
> view sniffer has to maintain to avoid generating of unncessary NACKs.
>
>  Please share your views.
>
>
>  Best Regards,
>  Ranjith Reddy. V
>  Sr. Software Engineer
>  Aricent-Bangalore.
>
> 11/20/2007 04:18 PM
>  >  > prohibited from using, copying, altering, or disclosing the contents
> of
>  > this