Re: [conex] Abstract marking and encoding in IPv6

[Ingemar Johansson S <[e-mail]>]

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

> -----Original Message-----
> From: Bob Briscoe [mailto:[e-mail]] 
> Sent: den 12 november 2010 16:50
> To: Woundy, Richard; Ingemar Johansson S
> Cc: [e-mail]
> Subject: Re: [conex] Abstract marking and encoding in IPv6
> 
> 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 
> 
>