Re: [rohc] Re: [MOBILE-IP] Comments on PILC draft

[Andrew Worsley <epaanwo@asac.ericsson.se>]

...
> >  I suggest segmentation using small segments and Nacks.
> 
> For TCP and most of the non-audio and non-video UDP, I agree that 
> the link should be almost error-free. This will be achieved 
> by some some combination of (channel) FEC and ARQ. Most links that
> ROHC is explicitly intended for can be run in such a mode.
> The price paid for this is delay, but that is ok for TCP and some UDP. 

   Note: I propose Nacks not Acks. I am not at all familiar with the
   qualities of the various link layers but using Acks is likely to require
   more data than Nacks if the segments are small enough that they are more
   likely than not to make it through okay.

> 
> NOTE that the added delay does not primarily come from the ARQ scheme,
> but from the increased interleaving needed to make the FEC work well. 
> 
....
> 
> I am not surprised. This suggests that performance-enhancing ARQ schemes
> over the link should use frames significantly smaller than typical TCP segments. 

   I am proposing Nacks rather than ARQ which might be slower.
> 
......
> 
> It seems like a tall order for the ROHC WG to develop an ARQ scheme given that
> the radio links explicitly mentioned in the charter already have such schemes.
> But, if the WG so desires, we can ask the ADs to add it to our charter.
> I would hesitate to do so before we're done with the tasks currently at
> hand, though.

   Okay - my suggestion was based on the idea that a) existing link layers
   were mostly lossy and b) that no one had done any work on a TCP profile which
   was needed.

   If all the link layers can provide low loss links then we can drop the
   use of Nacks. 

.....
> 
> For the links explicitly mentioned in the ROHC chater, the delay budget for 
> interactive voice will not tolerate using such a nack scheme. That is the 
> primary reason for doing the ROHC work in the first place.
> 
> Moreover, if the delay budget allowed using the nack scheme, it would almost
> certainly be a better overall system trade-off to improve the performance
> of the channel coding by adding interleaving than to deploy the nack scheme.
> 
> Mikael Degermark
> 
   If you way that ROHC can not usefully contribute to reliability i.e. all
   the link layers solve this perfectly well then I bow to your greater
   knowledge. If not perhaps there is a place for this work under the current
   charter. Do you have any references to hand about this matter for my own
   knowledge?

   	Thanks
		
		Andrew