Subject: RE: [rohc] draft-saifullah-rohc-tcp-early-comp*-00.txt

From: [email-masked]
Date: Tue, 5 Nov 2002 14:34:04 -0600

Ghyslain,
Thanks for sharing your views and opinions. Please see my embedded answers to your questions below.

Cheers,
Yousuf

-----Original Message-----
From: ext Ghyslain Pelletier [mailto:[email-masked]]
Sent: 05 November, 2002 1:16 PM
To: Saifullah Yousuf (NRC/Dallas)
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [rohc] draft-saifullah-rohc-tcp-early-comp*-00.txt

Yousuf,

My main points from the beginning are that the following is unclear to
me:

* Why mix context replication with "Early Compression Enabler"?

[Yousuf] Early Compression Enabler provides more generic use and the protocol changes done for Early Compression Enabler can be used to provide context replication. Reverse is not possible. If I had to choose between a protocol change which has narrow application and a protocol change which has wider application, I would choose the later. 
  
* Why supporting out-of-band mechanism within the ROHC-TCP profile
  would be within scope and would even be needed?

[Yousuf] There are two things one is Early Compression Enabler and other is Early Compression Mechanism (or out-of-band mechanism in the above question). I will repeat myself that I am not asking changes for any early compression mechanism. Early compression enabler provides compression from the very first TCP packet. Consider, http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-requirements-05.txt, section 2.3 req #4, "Short-lived TCP transfers: The scheme should provide mechanisms for efficient compression of short-lived TCP transfers, minimizing the size of context initiation headers." This requirements tells me that early compression enabler is within scope of ROHC-TCP. 

* Why can one not achieve "Early Compression" using context
  replication along with the out-of-band mechanism of the specific
  link technology, instead of requiring the opposite?

[Yousuf] The following are the points, which I have mentioned before also: 
- context replication does require a previous TCP connection so as to use that as base context. Early Compression Enabler can start compressing from the very first packet without any previous TCP connection. It doesn't require any ROHC-TCP base context
- context replication requires base context in B-mode and in FO/SO state, Early Compression Enabler doesn't require that.
- context replication requires storage of a base context. Early compression Enabler doesn't mandate such storage.

That's all. Obviously, it is up to the WG to make the decision regarding
the way forward with these documents. It seems that there is a
discussion ongoing, which I have decided to be part of, and I simply
wanted to provide my two cents - which I will repeat later again in this
mail because I still cannot find my answers.

> You are confusing Early Compression Enabler with an
> Early Compression Mechanism.

The "Early Compression Enabler" is additions to a ROHC-TCP profile in
the forms of compressor/decompressor logic, packet formats and feedback
formats. Example of "Early Compression Mechanisms" include PDP Context
Activation, RSVP signalling, Flow Mapping etc. Is this the correct
understanding?

[Yousuf] I think you are right in understanding. But your questions/conclusions seem to mix them up :)

I still think that we should be careful with such proposal like "Early
Compression Enabler". ROHC-TCP is meant to compress TCP/IP, and the
suggested approach of "Early Compression Enabler" seems to expand its
scope beyond this WG into providing hooks for potential technology
specific optimizations ("Early Compression Mechanisms"). The hooks I am
referring to here are not the specific out-of-band mechanism(s), but the
additions found in draft-saifullah-rohc-tcp-early-compression.txt.

ROHC-TCP should maintain a clear scope, and in particular when it is
related to such optimizations. Concepts behind such as the context
replication mechanism have been discussed and agreed on the basis that
it reuses exisiting header compression entities and contexts.

[Yousuf] Early Compression Enabler falls in the scope of ROHC-TCP. I have quoted a requirement above, and the enabler doesn't have any mechanism specific changes. I also like the concept of context replication. But, if we can provide another method which does not contradict with context replication plus can give more benefits plus can implement context replication also, then that is even better and should be considered. 

I also still think that the possible existence of out-of band mechanisms
should not be relevant to the definition of the ROHC-TCP profile, and
that the optimization that is suggested seems rather relevant to other
standardization bodies, eg they seem mostly related to optimize ROHC-TCP
implementations in various systems.

[Yousuf] I would maintain that I am not proposing any out-of-band mechanism for ROHC-TCP profile. In summary I have proposed changes in ROHC-TCP, to indicate that the early compression is enabled and IR packet is carrying the reduced header. There is no parameter for any out of band mechanism, such as PDP context activation or RSVP signaling in this. There is no logic at the ROHC-TCP compressor/decompressor which is tied to an early compression mechanism. In the last email I have mentioned the example of http://www.ietf.org/rfc/rfc3242.txt?number=3242 (A Link-Layer Assisted Profile for IP/UDP/RTP).  We can define a link-layer assisted profile, then why can't we define a profile for early compression enabler which is not even link specific.

> I am not asking ROHC-WG to support any out-of-band mechanism.

I have kept that in mind all along. The proposal however does require a
ROHC-TCP profile to include additional compressor/decompressor logic,
packet formats and feedback formats to support out-of-band mechanisms.
Is this the correct understanding?

[Yousuf] I am afraid not. The changes are to support early compression enabler. 

The intent with my comments is to provide feedback only pertaining to
the idea being the "Early Compression Enabler". I have tried to use the
reference to the other draft as a mean to show that "Early Compression
Enabler" is meant to accomodate link-layer specific mechanisms. I am not
referring to it by fear that the point is to standardize an "Early
Compression Mechanism" here in this WG. The use of RSVP to populate a
context is not new to me, as it was discussed in 3GPP2/TSG-P some months
ago and is still actual as part of one of their optimization solution
for RTP traffic.

However as I said previously, RSVP signalling and PDP context activation
may not be used everytime/everywhere ROHC-TCP is used.

[Yousuf] The proposed profile is optional. It is not tied to RSVP or PDP, a mechanism XYZ can also use this. I think optionality is applicable to context replication also, it is possible only in B-mode.

> I saw last response from Richard where he understood that the early
> compression provides a more general mechanism for allowing certain
> TCP/IP fields to be signalled outband, and this could incorporate
> context replication. So I don't understand the confusion. 

There is no confusion, simply different opinions.
Hopefully by this mail this is clearer.

Best regards,

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