Re: always including the context tag

[Brian E Carpenter <brc@zurich.ibm.com>]

On 2006-12-28 18:57, marcelo bagnulo braun wrote:
> In his review Iljitsch raises the following issue:
>
> my comments are online:
>
> please comment on the issue related to if we should support other 
> mechanisms for demux other than the context tag contained in the shim 
> payload header
>
> > 1. Always including the context tag
> >
> > As I've said many times, it's a very bad idea to unnecessarily 
> > increase overhead.

Has anyone looked at how this would interact with ROHC? The only context in
which I would agree with Iljitsch is where bandwidth is precious, and that
is exactly where ROHC should be used anyway. The context tag really
should be very compressible...
> well, i think having an additional header is the clean way to do this, 
> because there is an additional layer that is being inserted and the 
> layer needs to perform its signalling and this is achieved using a extra 
> header.

Yes, and an architecturally clean solution may quite legitimately make it
necessary to increase overhead.

    Brian
> >  Not only is this a bad thing in and of itself, but it also doesn't 
> > help convince people to forego IPv4+BGP in favor of IPv6+shim.
> >
> > Now if we only include the shim header containing the context tag 
> > after a failure, this could be a reasonable tradeoff. However, I'm 
> > quite sure that if and when shim6 is adopted, some people will use it 
> > to manage their traffic engineering by doing a locator change 
> > immediately and proceed in a shimmed state for the rest of the 
> > communication session.
> >
> > Earlier, I proposed to include a mandatory way for a host to instruct 
> > its peer to not include the shim header, pending mechanisms to do 
> > demultiplexing without the context tag. After reading the draft, I 
> > realize that this imposes some extra ICMP demultiplexing difficulties 
> > on implementations.
>
> depending on which fields do you use for the demux, i guess... i mean if 
> you use the flow label, there wouldn't be additional problems, i think, 
> right?
>
> >  So if the wg doesn't want to include this mandatory option, I suggest 
> > something different: since the traffic engineering mechanisms aren't 
> > really developed anyway and this problem is related to that, simply 
> > remove the locator preferences mechanism so that the context tag 
> > suppression can be included when proper traffic engineering is added.
>
> i don't think this is such a good idea...
>
> i mean i think locator preferneces are useful, i don't see why we should 
> remove them from the spec...
>
>
> > Also see draft-van-beijnum-shim6-suppress-header-00.txt (do it while 
> > you can, it expires next week...), this outlines a more fully formed 
> > mechanism to suppress the context tag header.
> >
> > I would very much like to see a consensus call on this subject.
> >
> >