Subject: [rohc] RE: Clarifications for the Implementer's guide

From: "Surtees, Abigail" <[email-masked]>
Date: Mon, 10 Jun 2002 10:19:54 +0100

Hi,

>According to my notes I have a third issue, which is about the 
>id of CSRC lists.
>
>There can be an extension-3 in UO-1-ID packets with a 
>compressed CSRC list in "RTP header flags and fields". CSRC 
>list uses encoding type 0 (section 5.8.6.1, page 120) and 
>every list could have an id, which is present if a compressor 
>wants to use this list as a future reference.
>
>The problem is that the compressor intends to use this list in 
>the future but the context isn't updated (because it's a UO-1 packet).
>
>So what should a decompressor do if it receives such a packet 
>(UO-1-ID, ext-3, CSRC list with gen_id)? Should it save the 
>list because the compressor may use it in the future or should 
>it forget it after the decompression of the current packet 
>because the context isn't updated?
>
This is a good question.  The context management of CSRC lists seems to be completely separate from the main context management.  This question seems to encompass others. 

 From 5.8.2.1:

       In U/O-mode, curr_list is inserted into the sliding window
       together with its generation identifier if the compressed list had
       a generation identifier and the sliding window does not contain a
       list with that generation identifier.  All lists with generations
       older than ref_id are removed from the sliding window.

so the decompressor context management depends only on gen_id. 

The translation table however seems to be updated whatever happens - whether the packet is UO-1 or UO-2, whether there is a gen-id present or not.

 From 5.8.1:

    The decompressor conceptually maintains a table that contains all
    (Index, item) pairs it knows about.  The table is updated whenever an
    (Index, item) pair is received (and decompression is verified by a
    CRC).  The decompressor retrieves the item from the table whenever an
    Index without an accompanying item is received.

Should translation table entries sent in a UO-1-ID ext 3 count towards L (at the compressor)/update the table (at the decompressor) or not?

I think we decided in Arizona that sending a UO-1-ID with an ext-3 is a very strange thing to do but obviously the decompressor does have to be able to handle it.

>Abbey, did I missed something?
>

I think a second point of discussion was that of acknowledgements and CSRC lists.  In O-mode a compressor receiving an acknowledgement can stop sending gen-id's early as with acknowledgements of the main update packets.  However, the translation table in U/O mode stores only the number of times a particular entry has been sent (5.8.1.2) (whereas R mode stores the SNs so that entries can be acknowledged (5.8.1.1)).  This means that even if an entry is acknowledged the compressor will still send the full information because as far as the translation table is concerned the entry hasn't yet been sent enough times to be sure that the decompressor has it.

Regards,

Abbie

>-- 
>Peter Kremer, MBA                  Tel: +36-1-437-7033
>Ericsson Hungary Ltd.              Fax: +36-1-437-7767
>Conformance Center ETH/RL/S        Mobile: +36-30-311-2118
>http://conformancelab.ericsson.se  E-mail: [email-masked]
>

---

From: Wang Hui <[email-masked]>
Date: Thu, 13 Jun 2002 20:43:53 +0800 (CST)

Hi folks here,

Our team is now implementing ROHC based on RFC3095.  We want to make it
run in our mobile IPv6 testbed to enhance some performance of our
mobile IPv6 demo-system.

Now we have only finished coding the U-mode and only realized the UDP only
profile.  But because our test bed is now a Wireless LAN(802.11), we have
found some problems with RFC3095.

o   The CID is allocated by the compressor.  But how to make it an unique
    identifier at the de-compressor side?  Because the WLAN is a shared
    layer 2 linker.  All the mobile nodes share the same channel within a
    WLAN.   If more than one mobile nodes send ROHC packet to one access
    router which will do de-compression, how to make the CIDs allocated by
    different mobile nodes be different?

o   The compressed packets' size may become less than 60 bytes.  60 bytes
    is the minimun size of a ethernet frame.  So if the size of a compressed
    packet is less than 60, it cannot be transefer in the ethernet.

In fact, the Wireless LAN is a broad band wireless environment.  We do not
need to use ROHC.  But I think the RFC3095 should consider these problems.

Best,
Wang Hui

--
 Wang Hui
 Next Generation Internet Research Team,
 InfoNet Lab, USTC
 http://mail.ustc.edu.cn/~whui
 Tel: +86-551-3603634

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 13 Jun 2002 15:18:28 +0200

Hi,

>     different mobile nodes be different?

The easiest way is to disambiguate e.g. using the source address.

>     packet is less than 60, it cannot be transefer in the ethernet.

This is one of the applications we had in mind when we designed the padding scheme.

Gruesse, Carsten

---

From: Wang Hui <[email-masked]>
Date: Fri, 14 Jun 2002 23:37:58 +0800 (CST)

> The easiest way is to disambiguate e.g. using the source address.

Yes, the source address may help it.

> This is one of the applications we had in mind when we designed the padding scheme.

Yes. Could you say more about your idea?