Subject: RE: [rohc] Question about Channel Parameters and U-Mode

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Thu, 23 Jan 2003 12:57:26 +0100

Matthew,

According to RFC 3095 section 4.1 (page 19):

   Negotiation

      In addition to the packet handling mechanisms above, the link
      layer MUST provide a way to negotiate header compression
      parameters, see also section 5.1.1.  (For unidirectional links,
      this negotiation may be performed out-of-band or even a priori.)

BR
/L-E

> -----Original Message-----
> From: Holmes, Matthew, CND Tech Dev, VF UK
> [mailto:[email-masked]]
> Sent: den 23 januari 2003 13:02
> To: [email-masked]
> Subject: [rohc] Question about Channel Parameters and U-Mode
> 
> 
> Hi All
> 
> I'm a bit confused about how channel parameters are 
> negotiated in U-Mode. If no feedback path is available then 
> U-Mode would be used.
> Can some one explain what happens with the channel parameters 
> in this case? 
> How would something like the PROFILES parameter be sent to 
> the compressor? 
> Although feedback is not required for U-Mode is a two-way 
> link mandatory for the link establishment?
> 
> Any help would be appreciated,
> 
> Thank you
> 
> Matthew Holmes
> 
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Alan Kennington <[email-masked]>
Date: Thu, 23 Jan 2003 23:12:12 +1030

>       this negotiation may be performed out-of-band or even a priori.)

This does raise the question as to whether, for the sake of
better standardisation, there should be a specified preferred a-priori
set of parameters for each link type.
For example, for PPP links, rfc3241, these parameters could be assumed:

MAX_CID		15
MRRU		0
MAX_HEADER	168
PROFILES	0x0000, 0x0001, 0x0002 

Then if you had two different brands of ROHC/PPP software from
different vendors, you should be able to get them interworking
on a simplex link without sending round the carrier pigeon.

In fact, on a simplex link, the above parameters are only relevant
to _ability_ to receive something - they do not affect the actual
interpretation of anything.

Therefore I conclude that, more or less, parameter negotiation is
superfluous on a simplex link, and maybe for duplex also,
if you assume that all implementations wake up as above or with
larger numbers or sets.
All you really need to know is that the other side has an ROHC implementation.

A fly in the ointment here is the fact that the PPP standard says
categorically (RFC 1661, p.1):

    The point-to-point Protocol is designed for simple links which
    transport packets between two peers. These links provide full-duplex
    simultaneous bi-directional operation, ...
 
PPP implementations (such as linux) seems to not allow a single
packet to pass until at least one LCP packet is received.
Therefore the problem lies in PPP, not in ROHC/PPP.

Maybe a set of standard out-of-the-box null-negotiation parameters
could be specified in RFC 3241 to take care of simplex links!?

Cheers,
Alan Kennington.

--------------------------------------------------------------------
    name: Dr. Alan Kennington
 website: http://www.topology.org/
    city: Adelaide, South Australia
  coords: 138.59 E, 34.88 S
timezone: UTC+1030 http://www.topology.org/site/timezone.html
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc