Subject: Re: [rohc] Congestion window tracking in RoHC-TCP

From: "Per Synnergren (EPL)" <[email-masked]>
Date: Thu, 14 Mar 2002 10:11:54 +0100

Hi Mark, Qian and Lars-Erik

Thanks for your comments!

>> Remember that the compressed header set is also part of the profile,
>> either the headers are written down manually in byte-aligned formats
>> or written as BNF for the "ROHC compressed header generator"
>> (EPIC-Lite). The "header generator" will produce different compressed
>> headers for optimal EPIC, so there will have to be two similar
>> ROHC profiles defined if one wants to define both Lite and the optimal
>> encoding. In general, we use to avoid multiple solutions and other
>> options, and we should probably do so also in this case. There
>> is always a tradeoff between simplicity, performance and also IPR
>> concerns.

>Fair point.  Perhaps I should say that the *input* to the header 
>generation process (with respect to the protocol description) is 
>identical in both cases, but that the output depends upon the generator 
>used..?

Hence, both the BNF-code and the "header generator" used (EPIC-LITE) should be defined in the standard for eventual TCP/IP EPIC-LITE RoHC-profiles and eventual other EPIC-LITE RoHC-profiles  (maybe SCTP). Thus, the implementation of EPIC in RoHC will not be protocoll independent due to the process of determining which header formats that EPIC-LITE "engine" should handle in RoHC. EPIC seems to me become a compressed header generator for RoHC. 

>> Of course, there may have other approaches to do so, such as 
>> use a fixed sliding window size for the w-LSB encoding. However, it may
>> hard to decide how to choose a proper value for this sliding window.

>Yes, and an implementer is free to be as inventive as he could to make it
>efficient (or choose what is described in the impl. section of the RFC).

There are, of course, other approaches to solve the "problem" with windowed-LSB. I do not think that we should just concentrate on one of many possible solutions. Congestion window tracking might be the best algorithm presented so far, but still I also think of it as an enhancment or an option.

>> So maybe it would be better to put congestion window estimation as an
>> enhancement, or an option. 

>My personal opinion is that this is the right way to see it, and let an
>implementer choose what mechanisms to use. It has nothing to do with the
>protocol, really.

I agree! 

Regards

/Pelle

____________________________________________
Per Synnergren, Ph.D., Lic. Eng., M.Sc.
Research Engineer

T/V - Multimedia Technologies
AWARE - Advanced Wireless Algorith Research
Ericsson Research

Ericsson AB
Box 920
S-971 28 Luleå, Sweden

Tel: +46 920 202392
Fax: +46 920 202099
Mobile: +46 70 2283386 

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

---

From: "West, Mark (ITN)" <[email-masked]>
Date: Fri, 15 Mar 2002 00:18:47 +0000

>> Fair point.  Perhaps I should say that the *input* to the header
generation
  >>  process (with respect to the protocol description) is  identical
  >>  in both cases, but that the output depends upon the generator  used..?
  >>

  >
  > Hence, both the BNF-code and the "header generator" used (EPIC-LITE)
  >  should be defined in the standard for eventual TCP/IP EPIC-LITE
  > RoHC-profiles and eventual other EPIC-LITE RoHC-profiles  (maybe
  > SCTP). Thus, the implementation of EPIC in RoHC will not be
  > protocoll independent due to the process of determining which
  > header formats that EPIC-LITE "engine" should handle in RoHC. EPIC
  > seems to me become a compressed header generator for RoHC.
  >

A RoHC profile (I assume!) will comprise a set of header formats and a
whole bunch of other information (states, modes, feedback, ...)  If I
have an EPIC profile for a protocol (say TCP), then I can generate 2
RoHC profiles: one based on EPIC and one on EPIC-lite.

Since the 4 (RoHC) profiles currently defined are mandatory, then there
is no negotiation.  I suppose that one of the other issues that needs to
be faced is how additional (RoHC) profiles will be handled?  Will they
all be made mandatory?  If not, how will negotiations be handled?

Have I understood your point correctly?

Cheers,

Mark.

-- 
Mark A. West, Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433

(Yes, I do know that my disclaimer is in an attachment.  And, no, I
didn't ask for it to be that way)

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Fri, 15 Mar 2002 01:58:19 +0100

> Since the 4 (RoHC) profiles currently defined are mandatory,

I'm not aware of anything that says that.

Only 0x0000 is mandatory ("MUST not be rejected").

> then there
> is no negotiation.

Much of the point of rohc-over-ppp is the negotiation of profiles.
Having two profiles for the same thing is only acceptable if one is
"mandatory" and the other "optional", i.e., when you implement the optional
one, you MUST implement the "mandatory" one (which, however, is not
mandatory per se).

Gruesse, Carsten

PS.: Gosh, I'm realizing that the rohc-over-ppp text:

   The set of profiles to be enabled is subject to negotiation.  Most
   initial implementations of ROHC implement profiles 0x0000 to 0x0003.
   This option MUST be supplied.

might be read to mean 0x0000 to 0x0003 are mandatory.  No, only the option
itself is mandatory -- there is little point in negotiating ROHC if you
don't agree on a profile to use...
Time for an AUTH48 clarification (e.g., exchanging second and third
sentence).

Gruesse, Carsten