Subject: RE: [rohc] Question about the relationship between packets and st ates

From: "Sarkar, Rajib" <[email-masked]>
Date: Sun, 20 Oct 2002 09:31:48 -0700

Hi,
	That clarifies my first doubt. But lets say you have different
traffic characteristics in the SO state, then should we fall back to the FO
state and send an IR-DYN packet (lets say we need to send an IR-DYN packet).
Or we can send an IR-DYN packet from SO state. Another example could be if
we need to synchronize the static fields, then should we fall back to the FO
state and send IR packets, or fall back to the IR state and send IR packets,
or we can send IR packets from the SO state. These questions eventually the
same question I asked in my original question, that is 
What kinds of packet we can send in IR state? (only IR packet)
What kinds of packet we can send in FO state?  (IR-DYN and UOR-2 packets, IR
packet only for refreshes)
What kinds of packet we can send in SO state? (All, but IR & IR-DYN packets
only for refreshes)
Is my answers to the above questions are right?
Regards
Rajib
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 18, 2002 11:02 PM
To: Sarkar, Rajib
Cc: 'Kausik Sinnaswamy'; [email-masked]
Subject: Re: [rohc] Question about the relationship between packets and
st ates

Hi!

> 	Does that mean that after sending the IR packet in the IR state,
> wait for some packets to be compressed and if the compressed packets
> conforms to previously established patters then transit to SO state? 
> Regards
> Rajib

"Wait for some packets to be compressed"? Do you mean buffer the
incoming packets at the compressor and analyze them?

"compressed packets conforms to previously established pattern"? Do you
mean the IP packets conform to the established pattern?

The approach would require that you buffer packets. And may change the
traffic characteristics. There is a delay introduced since you would
need to collect n number of packets before you send out the first
compressed packet. I am not in favor of changing the traffic
characteristics and thus would follow follow the approach, whereby after
sending k IR packets(corresponding to k IP packets), the compressor moves 
to the SO state. When the k+1 packet arrives at the compressor. It
determines if it can be compressed in the SO state else, it falls back
to the FO state.

Regards,
Sukanta

-- 
--------------------------------------------------------------------
Sukanta Kumar Hazra <[email-masked]>      
Institute for Communications Research
PGP-KEY: http://www.icr.a-star.edu.sg/~sukanta/skhkey.asc
PGP-ID: 0x8E084AD5 
Key-Fingerprint: 9C0D B00C C62A 7059 5314  99FC CE90 478A 8E08 4AD5
--------------------------------------------------------------------
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: [email-masked] (Sukanta Kumar Hazra)
Date: Mon, 21 Oct 2002 14:39:03 +0800

Hi! Rajib,

> Or we can send an IR-DYN packet from SO state. 

Hmm... if the compressor is in SO state and the packet is such that you need
to send IR-DYN then that would be a ("update") and according to the RFC
3095 state transition diagrams you should move to FO, if there is an update
in the stream.

> Another example could be if

IR -> IR + IR-DYN
FO -> Type 1 and Type 2 packets, + IR-DYN
SO -> Type 0 packets

Regards,
Sukanta