Re: [conex] Abstract marking and encoding in IPv6

[marcelo bagnulo braun <[e-mail]>]

El 12/11/10 16:50, Bob Briscoe escribió:
> Rich, Ingemar,
>
> I like Marcelo's idea of an interim session on encoding (presumably by 
> audio).

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) (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
> _______________________________________________
> conex mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/conex
>