Subject: RE: [Fwd: Re: [rohc] IPv6 deployment in profile 2 and 4]

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Wed, 14 Aug 2002 13:08:33 +0200

Ana,

> > > Perhaps your proposition is correct for IPv4 but it needs 
> > > something more simple for IPv6. As IP-Id is not in the
> > > original header, new format packets for IPv6 can be proposed?
> >
> > I would not say that something else is *needed* for IPv6, but
> > I would agree that one could argue for having different formats.
> > However, the approach taken in this document is the same as for
> > the IP/UDP profile, i.e. to have the same formats for both IPv4
> > and IPv6. The whole idea >with this profile is to be totally
> > based on the IP/UDP profile, with the simplest possible
> > modifications. 
> 
> I do not understand what you mean with simplest modifications?
> Are you refering that it is not possible to have a separate
> IPv6 format?

Well, I do not know exactly how to be clearer in this regard. I am
not saying that it is impossible to have a separate IPv6 format,
only that the current IP profile has not taken that approach, as
the intension was to make it as similar as possible to the IP/UDP
profile, which has ONE format for both v4 and v6. I've understood
your point, but that does not mean I agree or have a clear opinion
yet. That depends on what will happen with the IP profile, it 
might be something completely different than it currently is, not
based on profile 0x0001 and 0x0002.

> > > Another porblem we found, but perhaps you have the solution
> > > is: in the transition modes is that the IR, IR-Dyn and UOR-2
> > > do not contains the mode in which the compressor is working,
> > > only when you send UOR-2 with extension 3 then the transition
> > > is finish, in our implementation, the transition is blocked
> > > until an UOR-2+ext3 arrives! In profile 1, the mode is added
> > > in the original RTP header, then it is send in IR, IR-DYN,
> > > UOR-2 packets, then as in profile 4 there is not RTP then the
> > > mode is not added.
> >
> > I do not really understand what the problem is here. The
> > proposed IP profile has the same formats as the IP/UDP profile,
> > with mode bits in extension 3, exactly as for the IP/UDP/RTP
> > profile.
> 
> Well, in IP/UDP/RTP profile, we are not only sending mode in 
> extension 3, the RFC section 5.7.7.6 give the dynamic part of
> RTP protocol in which you are adding 2bits to send the mode. If
> this is like that, then this dynamic part could be sent also in
> IR-DYN and if IR packets used dynamic part. Then the decompressor
> can know in which mode compressor is working and he does not need
> to wait until an extension 3 arrives.

OK, so your comment was that IR and IR-DYN do not have mode bits
in the IP/UDP profile (and IP). That seem to be correct, and this
was originally the case also for the IP/UDP/RTP profile. Anyway, 
I can not see that this would cause any significant problem, you 
just have to send an UOR-2+Ext3 to signal mode. That might delay
the transition if you need to send IR/IR-DYN, but that does not
really matter since IR/IR-DYN are not affected by mode transitions
anyway.

> In the description of IP/UDP profile, the mode is only sent 
> in extension 3, but extension 3 is sent only when an updating
> is taking place an not normally.

Well, if you need to send mode bits, as you must do as a response
to a mode transfer request, then you will have to send an UOR-2
with Ext3, that is basically it. That is a kind of updating. The
principle is always to choose the smallest possible header to
send the information that must be conveyed, in this case the mode
value.

> We are thinking that perhaps for IP profile, sending UOR-2+ext3
> packets as the only possible response of compressor could be a
> solution to reduce the time ROHC pass in the transition.

I do not think that would be at all significant. The probability
of having to use IR/IR-DYN is low, so the chance of having that
happen at the same time as a mode transfer is initiated is
almost non existing (note that mode transitions should not happen
very often). Further, if this happens, the relative price of
sending an UOR-2 after the IR/IR-DYN is very low. In practice,
this would make the potential problem approximately zero. 

Anyway, the IP/UDP profile is defined like this, we just have to
live with what we have defined. Personally, I also think this is
fine, and I see no reason doing anything different for the IP
profile, if based on the IP/UDP profile.

Cheers,
/L-E

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