Re: [conex] Abstract marking and encoding in IPv6

[Bob Briscoe <[e-mail]>]

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).
>
>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: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Ingemar Johansson S
>Sent: Friday, November 12, 2010 9:29 AM
>To: [e-mail]
>Subject: [conex] Abstract marking and encoding in IPv6
>
>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 [phone]
>SMS/MMS [phone]
>[e-mail]
>www.ericsson.com
>Visit http://labs.ericsson.com !
>=================================
>_______________________________________________
>conex mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/conex
>_______________________________________________
>conex mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/conex

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design