Re: [conex] Abstract marking and encoding in IPv6

Hi

If we consider the idea to use bits from the flow label field I am not sure that 1 or 3 bits makes much of a difference as I suspect that much of the possible resistance will be along the lines "why allocate bits for an experiment?". But of course the equation
objection = f(bits) 
probably applies.
That said, what I really believe tilts the whole thing towards is support is.
A) ConEx helps operators to do things not otherwise possible, meaning operators want to buy it.
B) Vendors are willing to implement it

I would be interested to participate in an interim meeting. I guess one can do tricks with non-TCP applications to limit the need for green markings (such as more frequent RTCP reports in the beginning of an RTP-session).

/Ingemar

> -----Original Message-----
> From: Toby Moncaster [mailto:toby@moncaster.com] 
> Sent: den 14 november 2010 16:57
> To: 'marcelo bagnulo braun'; conex@ietf.org
> Subject: Re: [conex] Abstract marking and encoding in IPv6
> 
> This sounds a sensible suggestion. I think the aim of an 
> interim meeting should be to address two questions:
> 
> 1) What is the minimum number of (new) bits required for the 
> ConEx abstract mechanism in Matt's and Bob's draft?
> 
> 2) What is the maximum functionality we can get with just 1 new bit?
> 
> Obviously it would be really nice to think the two answers 
> are effectively the same (in other words 1 additional bit is 
> enough to implement the whole mechanism). 
> 
> Toby
> 
> 
> > -----Original Message-----
> > From: conex-bounces@ietf.org 
> [mailto:conex-bounces@ietf.org] On Behalf 
> > Of marcelo bagnulo braun
> > Sent: 14 November 2010 08:23
> > To: conex@ietf.org
> > Subject: Re: [conex] Abstract marking and encoding in IPv6
> > 
> > fwiw, this was a serious question. I mean, in v4 afaiu, we 
> would only 
> > get one bit and we could make it work. I would like to 
> understand how 
> > much can we do with one bit. I don't belive we could ask 
> for 4 bits in 
> > the flow label, and asking for 1 bit for conex seems much more 
> > reasonable to me.
> > 
> > 
> > 
> > El 12/11/10 3:23, marcelo bagnulo braun escribió:
> > > I would pose then the question: if you could only get 1 bit, what 
> > > could you do?
> > >
> > > Regards, marcelo
> > >
> > >
> > >
> > > El 12/11/10 3:19, ken carlberg escribió:
> > >> Ingemar,
> > >>
> > >>> + Encoding in IPv6: To me it seems like the only way to 
> make ConEx
> > >>> commercially attactive is to use some of the bits from the flow 
> > >>> label field. It was to me pretty clear that extension headers 
> > >>> (including the hop-by-hop options header) are not very 
> useful in 
> > >>> this context and it was also explained (Rich Woundy) that the
> > latter
> > >>> are not even useful for experimentation (my interpretation). So
> > what
> > >>> is required here is to convince 6man (and others) that 
> ConEx is a 
> > >>> good use case for N bits in the flow label field reserved for
> > ConEx.
> > >> given the constraints that CONEX is only producing experimental
> > work,
> > >> my feeling is that the odds are way against having 4 bits taken 
> > >> away from the flow label field for CONEX.  It would probably be 
> > >> best if the author/chairs could get the pulse of such a proposal 
> > >> from the 6man chairs, asap.  and from that, one could 
> decide which 
> > >> direction to pursue.
> > >>
> > >> -ken
> > >>
> > >> _______________________________________________
> > >> conex mailing list
> > >> conex@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/conex
> > >>
> > >
> > > _______________________________________________
> > > conex mailing list
> > > conex@ietf.org
> > > https://www.ietf.org/mailman/listinfo/conex
> > >
> > 
> > _______________________________________________
> > conex mailing list
> > conex@ietf.org
> > https://www.ietf.org/mailman/listinfo/conex
> 
> 
> 