Re: [conex] Abstract marking and encoding in IPv6

Hi

It is possible that you are right that 1 bit is the absolute pain limit.
Perhaps it is a good idea to discuss what kind of funtionality is possible with 
a) 3 bits
b) 2 bits
c) 1 bit 

a) is already given by the abstract marking draft.

/Ingeamr

> -----Original Message-----
> From: ken carlberg [mailto:carlberg@g11.org.uk] 
> Sent: den 15 november 2010 15:22
> To: Ingemar Johansson S
> Cc: Toby Moncaster; 'marcelo bagnulo braun'; conex@ietf.org
> Subject: Re: [conex] Abstract marking and encoding in IPv6
> 
> Hi Ingemar,
> 
> at the meeting, there was a speaker who brought up the 
> suggestion of taking out 4 bits from the 20 bit field for 
> "other use", and _retaining_ 16 bits for a smaller flow-ID.  
> So if that's the case, I think its being very optimistic for 
> any group (CONEX or anyone else) to immediate make a claim 
> for 3 of those 4 bits.  
> 
> I too like Marcelo's suggesting of just focusing on 1 bit, 
> since that was the original intent concerning IP4 during the 
> BoF discussions
> 
> cheers,
> 
> -ken
> 
> 
> On Nov 15, 2010, at 8:37 AM, Ingemar Johansson S wrote:
> 
> > 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
> >> 
> >> 
> >> 
> > _______________________________________________
> > conex mailing list
> > conex@ietf.org
> > https://www.ietf.org/mailman/listinfo/conex
> 
> 