Re: [conex] Abstract marking and encoding in IPv6

[ken carlberg <[e-mail]>]

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:[e-mail]] 
>> Sent: den 14 november 2010 16:57
>> To: 'marcelo bagnulo braun'; [e-mail]
>> 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: [e-mail] 
>> [mailto:[e-mail]] On Behalf 
>>> Of marcelo bagnulo braun
>>> Sent: 14 November 2010 08:23
>>> To: [e-mail]
>>> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/conex
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> conex mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/conex
>>>> 
>>> 
>>> _______________________________________________
>>> conex mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/conex
>> 
>> 
>> 
> _______________________________________________
> conex mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/conex