Subject: RE: [rohc] Do we need a special profile for Mobile IPv6 packets?

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Mon, 9 Dec 2002 15:37:42 +0100

Francis,

> > > the extensions headers are the most static part in a 
> > > Mobile IPv6 communication. For instance, the home
> > > address option is same in all packets when the source
> > > address in the IPv6 header changes at each handoff...
> > > So I fully agree with Wang.
> >   
> > Fine, then there should be no problem handling these 
> > efficiently with the list compression scheme.
>    
> no, the list compression scheme is not the right mechanism
> and some new profiles are really needed.

Then you will have to explain why list compression would not
handle these in a good way.

> > > > I am therefore not sure what explicit compression
> > > > mechanisms would be needed to compress these, since
> > > > the list compression scheme should already be capable
> > > > of compressing these headers, i.e. to initialize them
> > > > as list items, which can thereafter be omitted as long
> > > > as they do not change (and if they do, that can also
> > > > be handled).
> > >   
> > > IPv6 option extensions are not like the TCP options: 
> > > even if the list compression can handle them this can
> > > become highly suboptimal.
> >   
> > Then you will have to explain why. What you have stated
> > about these headers seem to indicate the opposite, i.e.
> > that list compression as it is currently defined should
> > handle this optimally.
>    
> the optimum is static (static-def in fact) for the real
> addresses which are in an extension header or the IPv6
> header. 

But in what way would it be inefficient to compress these
with the existing mechanisms? You would initiate a compressed
list with these headers within the IR-packets, and if they
are constant (as you say they are) you would get no
additional overhead in other packets.

> it seems you suggest that the list compression scheme is 
> as efficient as the "static" compression scheme? 

What I would like to see is a better motivation for defining
new profiles to address something that should already be
covered by existing profiles, i.e. to see examples of what
problems there are with the current profiles in this regard.
If generic mechanisms can be used to compress specific
header sets, that is the preferred solution. Defining new
compression profiles for each specific extension makes the
whole ROHC protocol set more complex and harder to get
deployed, and more alternatives do not help interoperability.

I am open to be convinced about the need for new mechanisms,
but some actual arguments why the existing solution is not
good enough have to be presented.

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

---

From: Ana Carolina Minaburo <[email-masked]>
Date: Mon, 09 Dec 2002 16:17:42 +0100

Lars-Erik,

I think the list compression as is in the RFC3095 is not really well 
explained. If you do not want to receive new draft with new profile for 
this kind of stuffs you need to clarify the use of the list and you need 
to convince others that this list is the best way to send extensions of 
IPv6 and Mobile IPv6.

Ana

---

From: Francis Dupont <[email-masked]>
Date: Mon, 09 Dec 2002 16:50:10 +0100

In your previous mail you wrote:

=> the fact the real addresses are not always in the IPv6 headers
when they are in the static-def class should be enough? If you agree
we need some new profiles to handle mobile IPv6 (when the standard
will be finished, cf RFC 3095 Abstract and section 3.4) then why not
try to provide the best solution we can?

Regards

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