New I-D has been submitted for draft-wan-ipdvb-rohc

["Ang Way Chuang <洪伟壮>" <[e-mail]>]

Hi all,
	I've just submitted the latest draft to IETF. The URL:
https://datatracker.ietf.org/idst/status.cgi?submission_id=9771

     The following is a summary of changes that went into this draft:
- Introduce a field called RefID (reference ID) in RCPNP message that 
used to ack/nack another message with the same ID.
- Reorganize the content so all causes of negative acknowledgement are 
now put under Negative acknowlegement section.
- Introduce heartbeat message in RCPNP that will be sent periodically 
when ROHC channel is idle. This is used to detect cases where 
compressor/decompressor terminates abnormally.
- In the section where interaction of RCPNP is shown, how RefID and ID 
are used was added. In addition, a case where abnormal termination is 
also shown.

Any comment on the latest draft?

In addition, we would like to discuss and possibly include the following 
ideas for the next revision:

1. Network with only 2 nodes may avoid the steps involve in the learning 
of network topology. Broadcast/multicast traffic can be compressed in 
this case. My guess is that this can achieved by gateway machine by 
detecting how many receiver frontend. If there is only one receiver 
frontend, then it is safe to assume the network only consists of 2 
nodes. Our definition of node is limited to receive capable feed. Of 
course, I am likely to be wrong.

2. How to enable compression of broadcast/multicast traffic if the 
network has more than 2 nodes? One idea is to have compressor gateway 
send a beacon signal about parameters of ROHC channel for 
broadcast/multicast traffic through uncompressed channel periodically 
There are several challenges that must be handled for this case.
- Firstly, if one of the receiver gateway can't accept the ROHC channel 
parameter (e.g doesn't support certain profile or doesn't ROHC 
decompression), then compression of broadcast/multicast can't proceed.
- There may be cases where receiver gateway joins the network after 
compressor gateway has started transmission of compressed packet. In 
this situation, the receiver gateway won't be able to decompress the 
packet until it receives the beacon and until the compressor's context 
falls back to IR state. Thus, context of compressor must periodically 
fall back to IR state after certain time (this may consumes more 
bandwidth than having uncompressed packet for certain cases depending on 
how frequent it falls back to IR state).

3. Only decompressor gateway can initiate the negotiation of ROHC 
channel in current draft. I think it is sufficient, so is there a need 
to specify a way to let compressor gateway to initiate the negotiation 
of ROHC channel?


Anyway, I had a quick glance at the drafts related to security extension 
  mentioned in the last IETF meeting, but I have no idea how it can be 
used to overcome the problem of address spoofing vulnerability mentioned 
in our draft.

Thanks for reading this lengthy email.

Regards,
Ang Way Chuang