RE: [rohc] Implementation parameters and signals

[Mikael Degermark <micke@cs.arizona.edu>]

Zhigang and Juha, 

A couple of comments:

At 11:12 AM 10/19/00 +0300, juha.kalliokulju@nokia.com wrote:
>Moi Zhigang,
>
>Comments below.
>
>-jk-
>
>> -----Original Message-----
>> From: EXT zhigang.liu@nokia.com [mailto:zhigang.liu@nokia.com]
>> Sent: 18. lokakuuta 2000 20:06
>> To: lars-erik.jonsson@ericsson.com; juha.kalliokulju@nokia.com;
>> rohc@cdt.luth.se
>> Subject: RE: [rohc] Implementation parameters and signals
>> 
>> 
>> Yes. Although the current draft does not mention it explicitly,
>> I guess one compressor can have multiple channels connected to 
>> a decompressor on the other side. When a packet is delivered to 
>> compressor/decompressor, the link layer should indicate the channel 
>> ID over which the packet is received.
>> 
>> (Should we add something to section 4.2? For example, CID is per
>> channel. Therefore, if multiple channels are associated with one 
>> compression entity, the context for a stream is uniquely 
>> identified by 
>> the tuple (channel ID, CID). ) 

No changes are needed. 5.1.3 already state that CIDs are per-channel. 

To make this work, it is only necessary to define channels in the proper way.
(not the task of ROHC)

>> Of course, the above assumes one compressor/decompressor per PDCP.
>> But when I read the early spec of PDCP, it looks that one PDCP
>> can be associated with multiple compression instances. 

I'm not sure what that means. The protocol need not assume anything about how
the software is organized in this regard. The only thing needed is that CIDs are
per-channel, and they already are. 


>> If I 
>> understand correctly, the 5 bits you mentioned are for packet 
>> type at PDCP layer, 
>
>-jk- Correct.
>
>> not for the purpose of demultiplexing
>> to different compression instances. 
>
>-jk- If I understood this correct I would say no. The idea has been that
>with those 5 bits (if the PDCP PDU type has been selected to indicate
>000=PID field used for header compression information) are used for packet
>type information+the header compressor information i.e. the PID indicates
>both the algorithm and the packet type if multiple compression algorithm
>types are used over the same link. 
>
>> So, it looks a little bit
>> weird. I guess the PCDP can map the PDCP_PT to channel_ID
>> and hide this "twist" from the compression instance.
>
>-jk- I didn't get the point. 
>
>> Then,
>> each compression instance will only see multiple channels
>> that all configured to small CID space (thus, allow zero-byte CID).
>
>-jk- If I understood this correctly the functionality to be put to PDCP
>would require separation of flows before header compressor so that each
>compressor instance would only treat one data flow (resulting in 0 byte
>CID). After compression PDCP would indicate different flows with CID and
>multiplex them over the radio link. The problem I seen in this configuration
>is that PDCP would need to study IP and UDP headers before forwarding the
>packets to compressor which would do the same (of course this can be
>optimised in implementation but I'm trying to figure how to draw boxes in
>spec and describe the functionality of each of them)

So the question is who decides what packets belong to which channel. I would
expect that all packets delivered to a particular compressor is examined and it is
determined which context to use. The context gives a CID and can also give
a channel identifier. The channel identifier is given to PDCP together with the
packet. At the receiving side, the channel id is taken from the PDCP header and
given to the decompressor together with the packet. The pair (CID, Channel ID)
is used to select the context to use. 

Doesn't seem complex at all. Some additional stuff may be needed to select which 
radio channel to use, but that needs to be there anyway. 

Cheers, 

Micke