Subject: [conex] Abstract marking and encoding in IPv6

From: Ingemar Johansson S <[email-masked]>
Date: Fri, 12 Nov 2010 02:29:08 +0100

Hi

Given yesterdays presentation on the abtract encoding mechanism and the IPv6 encoding options my findings are:

+ 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.

+ Encoding of abstract mechanism: Now that I (believe I) understand the green marking (and the necessity of it) it is to me quite obvious that 5 codepoints are needed, thus 3 bits are needed, this leaves 1 unused codepoint waiting for an interesting use case...   

/Ingemar

=================================
INGEMAR JOHANSSON  M.Sc. 
Senior Research Engineer 

Ericsson AB
Multimedia Technologies
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]
www.ericsson.com 
Visit http://labs.ericsson.com !
=================================

---

From: ken carlberg <[email-masked]>
Date: Thu, 11 Nov 2010 21:19:51 -0500

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 (inc…

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 12 Nov 2010 03:23:15 +0100

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ó:
> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex
>

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 12 Nov 2010 03:30:44 +0000

> 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).

This might be a good time to clarify my comments.

First, the context of my comments (not useful for experimentation) was focused on experiments across the Internet, not on lab experiments where I am sure any approach will work.

Second, some folks behind me at the mike during the Conex session asserted that the "slow path" through some commercial routers could be 1000 times slower than the usual "fast path", maybe even 100,000 times slower. Personally I didn't quote a performance difference but I have seen huge discrepancies between the slow and fast paths on some commercial routers. This affects the capacity available for the experimental traffic.

Third, there was something I forgot to mention at the mike, which is a big deal. Oftentimes, forwarding traffic through the router's slow path implies sending packets to the main router CPU for processing. The main router CPU is also performing other key activities, particularly exchanging routing protocol messages, updating the RIB and FIB, supporting network management queries, generating statistics, etc. So if there is a significant amount of experimental traffic, it *might* impact the functioning of the router itself, depending on the relative priority of the experimental traffic and each of these activities.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ingemar Johansson S
Sent: Friday, November 12, 2010 9:29 AM
To: [email-masked]
Subject: [conex] Abstract marking and encoding in IPv6

Hi

/Ingemar

Ericsson AB
Multimedia Technologies
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289

---

From: Roland Bless <[email-masked]>
Date: Fri, 12 Nov 2010 12:48:13 +0100

Hi,

On 12.11.2010 02:29, Ingemar Johansson S wrote:
> + 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.

It's not totally clear to me why extension headers aren't the right
approach: the main obstacle seems to be that broken implementations
punt the packet to the slow path as soon as there is a hop-by-hop
option present. For a CONEX supporting router you could implement
that new conex h-b-h option in the fast path, and old ones should ignore
the unknown option and leave the packet in the fast path. IMHO it's
better to get that fixed asap since otherwise the h-b-h extension
headers aren't very useful. Thus, the natural choice would be to use the
foreseen IPv6 extension mechanism.

Regards,
 Roland

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 12 Nov 2010 15:50:05 +0000

Rich, Ingemar,

I like Marcelo's idea of an interim session on encoding (presumably by audio).

Beyond the 3 techniques in Suresh's presentation, 
there are two other possibilities I can think of:
4) (proposed by Lars) use bits in an existing v6 hop-by-hop options header
5) use GUT <https://datatracker.ietf.org/doc/draft-manner-tsvwg-gut/>

4) The idea here is that the IPv6 main header is 
not the only header that today's v6 routers 
already support that might offer some space. For 
instance there might be a possibility to 
re-purpose the IPv6 fragmentation header (I chose 
this particularly, because we might be able to 
repeat the same trick in the fragmentation fields 
of the IPv4 header). There might be ideas for 
using other existing v6 hop-by-hop headers too.

5) Here's an intro to why GUT could be a 
principled alternative, which I recently sent 
offlist to the authors of <draft-ietf-6man-exthdr>:

>GUT was originally designed for tunnelling new 
>transport layer protocols. But in a change 
>between -01 and -02 we took the insight from Rob 
>Hancock that any router with IP header extension 
>code will know where to look, so it's 
>unnecessary to have routers that don't know 
>about new extensions checking through a string 
>of extensions looking for stuff they don't have code for.
>
>Instead, we hid IP extension headers behind a 
>UDP header. Packets then go through NATs, 
>firewalls and any assorted meddleboxes and muddleboxes.
>
>And you don't get punted to the slow path.
>
>Although it doesn't look principled, it depends 
>how you look at it - see Tng (transport next-gen).
>
>We still need to define the principles for how 
>it interacts with IPsec etc. So I'm not saying 
>it's completely thought through. But it works.

There's been some conversation on GUT between us 
since, that we ought to summarise to the ConEx list once it has finished.

Bob

At 03:30 12/11/2010, Woundy, Richard wrote:
> > 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).
>
>First, the context of my comments (not useful 
>for experimentation) was focused on experiments 
>across the Internet, not on lab experiments 
>where I am sure any approach will work.
>
>Second, some folks behind me at the mike during 
>the Conex session asserted that the "slow path" 
>through some commercial routers could be 1000 
>times slower than the usual "fast path", maybe 
>even 100,000 times slower. Personally I didn't 
>quote a performance difference but I have seen 
>huge discrepancies between the slow and fast 
>paths on some commercial routers. This affects 
>the capacity available for the experimental traffic.
>
>Third, there was something I forgot to mention 
>at the mike, which is a big deal. Oftentimes, 
>forwarding traffic through the router's slow 
>path implies sending packets to the main router 
>CPU for processing. The main router CPU is also 
>performing other key activities, particularly 
>exchanging routing protocol messages, updating 
>the RIB and FIB, supporting network management 
>queries, generating statistics, etc. So if there 
>is a significant amount of experimental traffic, 
>it *might* impact the functioning of the router 
>itself, depending on the relative priority of 
>the experimental traffic and each of these activities.
>
>-- Rich
>
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Ingemar Johansson S
>Given yesterdays presentation on the abtract 
>encoding mechanism and the IPv6 encoding options my findings are:
>
>+ 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.
>
>+ Encoding of abstract mechanism: Now that I 
>(believe I) understand the green marking (and 
>the necessity of it) it is to me quite obvious 
>that 5 codepoints are needed, thus 3 bits are 
>needed, this leaves 1 unused codepoint waiting 
>for an interesting use case...
>
>/Ingemar
>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 14 Nov 2010 07:35:44 +0100

> I like Marcelo's idea of an interim session on encoding (presumably by 

yes, the idea was to make a virtual interim meeting focussed in the 
encoding (but not limited to it)

i think we could try to arrange that for the last week of january. I 
will talk with my co chair and ADs and come back to you on this.

Regards, marcelo

>
> Beyond the 3 techniques in Suresh's presentation, there are two other 
> possibilities I can think of:
> 4) The idea here is that the IPv6 main header is not the only header 
> that today's v6 routers already support that might offer some space. 
> For instance there might be a possibility to re-purpose the IPv6 
> fragmentation header (I chose this particularly, because we might be 
> able to repeat the same trick in the fragmentation fields of the IPv4 
> header). There might be ideas for using other existing v6 hop-by-hop 
> headers too.
>
> 5) Here's an intro to why GUT could be a principled alternative, which 
> I recently sent offlist to the authors of <draft-ietf-6man-exthdr>:
>
>> GUT was originally designed for tunnelling new transport layer 
>> protocols. But in a change between -01 and -02 we took the insight 
>> from Rob Hancock that any router with IP header extension code will 
>> know where to look, so it's unnecessary to have routers that don't 
>> know about new extensions checking through a string of extensions 
>> looking for stuff they don't have code for.
>>
>> Instead, we hid IP extension headers behind a UDP header. Packets 
>> then go through NATs, firewalls and any assorted meddleboxes and 
>> muddleboxes.
>>
>> Although it doesn't look principled, it depends how you look at it - 
>> see Tng (transport next-gen).
>>
>> We still need to define the principles for how it interacts with 
>> IPsec etc. So I'm not saying it's completely thought through. But it 
>> works.
>
> There's been some conversation on GUT between us since, that we ought 
> to summarise to the ConEx list once it has finished.
>
>
> Bob
>
>> > 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).
>>
>> First, the context of my comments (not useful for experimentation) 
>> was focused on experiments across the Internet, not on lab 
>> experiments where I am sure any approach will work.
>>
>> Second, some folks behind me at the mike during the Conex session 
>> asserted that the "slow path" through some commercial routers could 
>> be 1000 times slower than the usual "fast path", maybe even 100,000 
>> times slower. Personally I didn't quote a performance difference but 
>> I have seen huge discrepancies between the slow and fast paths on 
>> some commercial routers. This affects the capacity available for the 
>> experimental traffic.
>>
>> Third, there was something I forgot to mention at the mike, which is 
>> a big deal. Oftentimes, forwarding traffic through the router's slow 
>> path implies sending packets to the main router CPU for processing. 
>> The main router CPU is also performing other key activities, 
>> particularly exchanging routing protocol messages, updating the RIB 
>> and FIB, supporting network management queries, generating 
>> statistics, etc. So if there is a significant amount of experimental 
>> traffic, it *might* impact the functioning of the router itself, 
>> depending on the relative priority of the experimental traffic and 
>> each of these activities.
>>
>> -- Rich
>>
>> Given yesterdays presentation on the abtract encoding mechanism and 
>> the IPv6 encoding options my findings are:
>>
>> + Encoding of abstract mechanism: Now that I (believe I) understand 
>> the green marking (and the necessity of it) it is to me quite obvious 
>> that 5 codepoints are needed, thus 3 bits are needed, this leaves 1 
>> unused codepoint waiting for an interesting use case...
>>
>> /Ingemar
>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 14 Nov 2010 09:23:16 +0100

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
>
>
>
>>> 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
>>

---

From: "Toby Moncaster" <[email-masked]>
Date: Sun, 14 Nov 2010 15:56:42 -0000

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

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of marcelo bagnulo braun
> Sent: 14 November 2010 08:23
> To: [email-masked]
> Subject: Re: [conex] Abstract marking and encoding in IPv6
>

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 15 Nov 2010 14:21:00 +0100

Hi

I admit that I may not get the whole picture why packets with hop-by-hop headers are punted to the slow path but I am not sure that it is a broken behavior especially as as the additional complexity caused by the extension header is impossible to see just by looking at the 3MSBs. So I am not really sure that you can solve this problem but I will have to leave this to the experts in this area to determine

Even if the "general punt to slow path" problem is solved, it is likely that ConEx enabled routers will have to put ConEx packets in the slow path and this I believe limits the use of ConEx policing to relatively low bitrate interfaces, perhaps this is no problem if the core is overprovisioned, I don't know.

ConEx marking is special in the sense that the complexity of the ConEx marking can be made very low. If we put the MPLS issue (another problem) aside one can implement a very cheap policer in a high-speed interface just by counting the average ConEx rate (=don't care about the packet size). This of course means that a ConEx enabled routher does not need to do too much lookup in each packet. Use of bits from the flow label field can make this possible. Other encodings like extension headers and GUT can be more problematic in this respect.

Regards
Ingemar

> From: Roland Bless [mailto:[email-masked]] 
> Sent: den 12 november 2010 12:48
> To: Ingemar Johansson S
> Cc: [email-masked]
> > field. It was to me pretty clear that extension headers 
> (including the 
> > 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.
> 
> approach: the main obstacle seems to be that broken 
> implementations punt the packet to the slow path as soon as 
> there is a hop-by-hop option present. For a CONEX supporting 
> router you could implement that new conex h-b-h option in the 
> fast path, and old ones should ignore the unknown option and 
> leave the packet in the fast path. IMHO it's better to get 
> that fixed asap since otherwise the h-b-h extension headers 
> aren't very useful. Thus, the natural choice would be to use 
> the foreseen IPv6 extension mechanism.
> 
> Regards,
>  Roland
>

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 15 Nov 2010 14:37:09 +0100

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

> From: Toby Moncaster [mailto:[email-masked]] 
> Sent: den 14 november 2010 16:57
> To: 'marcelo bagnulo braun'; [email-masked]
> 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?
> 
> 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
> 
> 
> [mailto:[email-masked]] On Behalf 
> > Of marcelo bagnulo braun
> > >> 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
> > >>

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 15 Nov 2010 15:20:31 +0100

Hi

The possible issue I see with GUT is that endpoints need to be upgraded to understand GUT, of course any endpoint needs to be upgraded anyway to understand ConEx so this is probably not an valid issue. 
The second issue is the additional packet overhead caused but GUT. I admit that you have an additional overhead (8 bytes?) with IPv6 hop-by-hop options but this overhead is bigger. 
But.. sure, it may perhaps be the best alternative at least for experimental use.

/Ingemar

> From: Bob Briscoe [mailto:[email-masked]] 
> Sent: den 12 november 2010 16:50
> To: Woundy, Richard; Ingemar Johansson S
> Cc: [email-masked]
> Beyond the 3 techniques in Suresh's presentation, there are 
> two other possibilities I can think of:
> 4) The idea here is that the IPv6 main header is not the only 
> header that today's v6 routers already support that might 
> offer some space. For instance there might be a possibility 
> to re-purpose the IPv6 fragmentation header (I chose this 
> particularly, because we might be able to repeat the same 
> trick in the fragmentation fields of the IPv4 header). There 
> might be ideas for using other existing v6 hop-by-hop headers too.
> 
> 5) Here's an intro to why GUT could be a principled 
> alternative, which I recently sent offlist to the authors of 
> <draft-ietf-6man-exthdr>:
> 
> >protocols. But in a change between -01 and -02 we took the 
> insight from 
> >Rob Hancock that any router with IP header extension code will know 
> >where to look, so it's unnecessary to have routers that don't know 
> >about new extensions checking through a string of extensions looking 
> >for stuff they don't have code for.
> >
> >Instead, we hid IP extension headers behind a UDP header. 
> Packets then 
> >go through NATs, firewalls and any assorted meddleboxes and 
> >muddleboxes.
> >
> >We still need to define the principles for how it interacts 
> with IPsec 
> >etc. So I'm not saying it's completely thought through. But it works.
> 
> There's been some conversation on GUT between us since, that 
> we ought to summarise to the ConEx list once it has finished.
> 
> 
> Bob
>

---

From: ken carlberg <[email-masked]>
Date: Mon, 15 Nov 2010 09:22:29 -0500

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

---

From: Roland Bless <[email-masked]>
Date: Mon, 15 Nov 2010 22:55:26 +0100

Hi,

On 15.11.2010 14:21, Ingemar Johansson S wrote:
> I admit that I may not get the whole picture why packets with
> hop-by-hop headers are punted to the slow path but I am not sure that
> it is a broken behavior especially as as the additional complexity
> caused by the extension header is impossible to see just by looking
> at the 3MSBs. So I am not really sure that you can solve this problem
> but I will have to leave this to the experts in this area to
> determine

I'm not a hardware expert either, but I think that it should be possible
to have a simple multifield match for an extension header in the fast
path. I didn't state that looking at the 3MSB (I assume you mean bits
here) is sufficient. You have to check the next header field value
+ the option type. If option type is "conex" then you may set the
appropriate value in the option. I think that this can be easily
done in the fast path since multifield classifiers and token bucket
policers can be realized there, too.

> Even if the "general punt to slow path" problem is solved, it is
> likely that ConEx enabled routers will have to put ConEx packets in
> the slow path and this I believe limits the use of ConEx policing to

I don't think that slow path processing will be necessary.

> relatively low bitrate interfaces, perhaps this is no problem if the
> core is overprovisioned, I don't know.

 > ConEx marking is special in the sense that the complexity of the
> ConEx marking can be made very low. If we put the MPLS issue (another
> problem) aside one can implement a very cheap policer in a high-speed
> interface just by counting the average ConEx rate (=don't care about
> the packet size). This of course means that a ConEx enabled routher
> does not need to do too much lookup in each packet. Use of bits from
> the flow label field can make this possible. Other encodings like
> extension headers and GUT can be more problematic in this respect.

I doubt that looking for a conex extension header is a very costly task...

Regards
 Roland

> Regards Ingemar
> 
>> -----Original Message----- From: Roland Bless
>> [mailto:[email-masked]] Sent: den 12 november 2010 12:48 To:
>> Ingemar Johansson S Cc: [email-masked] Subject: Re: [conex]
>> Abstract marking and encoding in IPv6
>> 
>> Hi,
>> 
>>> + 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
>> It's not totally clear to me why extension headers aren't the
>> right approach: the main obstacle seems to be that broken 
>> implementations punt the packet to the slow path as soon as there
>> is a hop-by-hop option present. For a CONEX supporting router you
>> could implement that new conex h-b-h option in the fast path, and
>> old ones should ignore the unknown option and leave the packet in
>> the fast path. IMHO it's better to get that fixed asap since
>> otherwise the h-b-h extension headers aren't very useful. Thus, the
>> natural choice would be to use the foreseen IPv6 extension
>> mechanism.
>> 
>> Regards, Roland

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 16 Nov 2010 09:19:47 +0100

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

> From: ken carlberg [mailto:[email-masked]] 
> Sent: den 15 november 2010 15:22
> To: Ingemar Johansson S
> Cc: Toby Moncaster; 'marcelo bagnulo braun'; [email-masked]
> 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
> 
> 
> > 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.
> > A) ConEx helps operators to do things not otherwise 
> possible, meaning operators want to buy 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
> > 
> > 
> >> 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?
> >> 
> >> 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
> >> 
> >>

---

From: Steven Blake <[email-masked]>
Date: Tue, 16 Nov 2010 10:34:25 -0500

> I doubt that looking for a conex extension header is a very costly task...

Adding functionality to fast-path forwarding adds cost (extra
memory/TCAM accesses; extra code in firmware memory).  Some (but not
all) fast-path implementations are non-programmable.  Don't
underestimate the reluctance of vendors to add additional functionality
to fast-path forwarding.

Regards,

// Steve

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 17 Nov 2010 07:53:41 +0100

Thanks for dropping by Steven. 

Can anyone point to a "101 fastpath vs. slowpath" article that tries to exlain with some more detail the issues with fast and slowpath processing ?. My personal knowledge is limited to the a book "Network routing" by Mehdi and Ramasamy but it does not provide too much details on this subject. 

/Ingemar

> From: Steven Blake [mailto:[email-masked]] 
> Sent: den 16 november 2010 16:34
> To: Roland Bless
> Cc: Ingemar Johansson S; [email-masked]
> > > hop-by-hop headers are punted to the slow path but I am not sure 
> > > that it is a broken behavior especially as as the additional 
> > > complexity caused by the extension header is impossible 
> to see just 
> > > by looking at the 3MSBs. So I am not really sure that you 
> can solve 
> > > this problem but I will have to leave this to the experts in this 
> > > area to determine
> > 
> > I'm not a hardware expert either, but I think that it should be 
> > possible to have a simple multifield match for an extension 
> header in 
> > the fast path. I didn't state that looking at the 3MSB (I 
> assume you 
> > mean bits
> > appropriate value in the option. I think that this can be 
> easily done 
> > in the fast path since multifield classifiers and token bucket 
> > > problem) aside one can implement a very cheap policer in a 
> > > high-speed interface just by counting the average ConEx 
> rate (=don't 
> > > care about the packet size). This of course means that a ConEx 
> > > enabled routher does not need to do too much lookup in 
> each packet. 
> > > Use of bits from the flow label field can make this 
> possible. Other 
> > > encodings like extension headers and GUT can be more 
> problematic in this respect.
> > 
> underestimate the reluctance of vendors to add additional 
> functionality to fast-path forwarding.
> 
> 
> Regards,
> 
> // Steve
> 
>

---

From: Roland Bless <[email-masked]>
Date: Wed, 17 Nov 2010 09:46:02 +0100

Hi Steve,

> underestimate the reluctance of vendors to add additional functionality

I think it's pretty obvious that adding functions (such as conex
processing) to the fast path creates cost - even this special
flow label hack + conex processing code will create cost.
My original point was that some _basic_ header extension processing
code should be down in the fast path (like forwarding of non-supported
or non-interesting hop-by-hop options) while more complex processing
can be surely up in the slow path. So it's better to put some basic
header extension processing support into the ASIC before we run
into the same trap next time over and over again...

Regards,
 Roland

---

From: Steven Blake <[email-masked]>
Date: Wed, 17 Nov 2010 10:22:16 -0500

On Wed, 2010-11-17 at 07:53 +0100, Ingemar Johansson S wrote:

> Can anyone point to a "101 fastpath vs. slowpath" article that tries
> to exlain with some more detail the issues with fast and slowpath
> processing ?. My personal knowledge is limited to the a book "Network
> routing" by Mehdi and Ramasamy but it does not provide too much
> details on this subject. 

On boxes that distinguish between "fast" and "slow" path (virtually
anything from 1 Gig up in the provider space, and virtually all Ethernet
boxes), the "fast path" is implemented in specialized silicon, with
access to fast memory (e.g., RLDRAM II, QDR SRAM) and/or TCAM.  These
devices are programmed either in Verilog (making recompiles *very*
expensive) or specialized firmware (e.g., NPUs).  Often the NPU firmware
is stored on on-chip memory, limiting the amount of forwarding
functionality that can be implemented.  There is a tight budget of
memory cycles per-packet that can allow sustained wire-speed
performance.  Different NPU architectures are more flexible vis-a-vis
trading off packet forwarding rate for functionality.  In the case of
hard-coded forwarding ASICs, extending "fast path" functionality means
replacing linecards.

"Slow path" forwarding is implemented in general purpose CPUs.  Usually
there is a 2-3 order-of-magnitude difference in packet rate between
"slow path" and "fast path".

The goal is for 99.999% of packets to stay in the "fast path".    If use
of an IPv6 Hop-by-hop option becomes common, vendors have to implement
support for that in the "fast path".  But there is a cost to that, and
it will take a while to deploy, so you have to be realistic about how
easy it is to introduce new Hop-by-hop options that would get used on a
non-trivial fraction of packets.

Regards,

// Steve

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 24 Nov 2010 08:30:55 +0100

Thanks for the primer. 
I guess it can be interpreted in many ways.
 
My interpretation is that extension headers is not a very good idea. Therefore I believe the WG should consider the option to use 1 bit from the flowlabel and see what can be achieved with that. 
Of course this extra bit means extra processing in the "fast path" for a ConEx aware router but it can be safely ignored by any non-ConEx router. Header extension to means that pattern matching needs to be done on every packet to see if extension X is supported by the router and if processing should be in the fast or slow path.

my 5€
Regards 
/Ingeamr

> Sent: den 17 november 2010 16:22
> To: Ingemar Johansson S
> Cc: Roland Bless; [email-masked]
> Subject: RE: [conex] Abstract marking and encoding in IPv6
> 
> On boxes that distinguish between "fast" and "slow" path 
> (virtually anything from 1 Gig up in the provider space, and 
> virtually all Ethernet boxes), the "fast path" is implemented 
> in specialized silicon, with access to fast memory (e.g., 
> RLDRAM II, QDR SRAM) and/or TCAM.  These devices are 
> programmed either in Verilog (making recompiles *very*
> expensive) or specialized firmware (e.g., NPUs).  Often the 
> NPU firmware is stored on on-chip memory, limiting the amount 
> of forwarding functionality that can be implemented.  There 
> is a tight budget of memory cycles per-packet that can allow 
> sustained wire-speed performance.  Different NPU 
> architectures are more flexible vis-a-vis trading off packet 
> forwarding rate for functionality.  In the case of hard-coded 
> forwarding ASICs, extending "fast path" functionality means 
> replacing linecards.
> 
> "Slow path" forwarding is implemented in general purpose 
> CPUs.  Usually there is a 2-3 order-of-magnitude difference 
> in packet rate between "slow path" and "fast path".
> 
> of an IPv6 Hop-by-hop option becomes common, vendors have to 
> implement support for that in the "fast path".  But there is 
> a cost to that, and it will take a while to deploy, so you 
> have to be realistic about how easy it is to introduce new 
> Hop-by-hop options that would get used on a non-trivial 
> fraction of packets.
> 
> 
> Regards,
> 
> // Steve
> 
>