[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: Conex(was Re: Hop-by-Hop Extension Header processed in Slow Path?)
From:       John Leslie <john () jlc ! net>
Date:       2011-02-04 23:49:10
Message-ID: 20110204234910.GC41896 () verdi
[Download RAW message or body]

Suresh Krishnan <suresh.krishnan@ericsson.com> wrote:
> On 11-02-04 01:05 PM, Thomas Narten wrote:
> 
>> Right off, I don't have enough understanding of what kind of
>> architecture conex envisions to have any useful thoughts, but if you
>> are thinking of using HBH options, the effort is certainly faces
>> significant challenges.

   I don't believe anyone on the ConEx list _likes_ the idea of using
hop-by-hop options -- it's just hard to grok the alternatives.

>> But rather than saying "don't use HBH" I'll suggest that you make the
>> case for why HBH is the least worse way of designing conex.

   IMHO, that's a null case. ;^)

>> Understanding that use of HBH for anything implies serious
>> questions about whether anyone will actually implement/deploy it.

   We don't even rise to the level of discussing implementation in
routers.

> Fully agree with you. Hop-by-hop options are not really suitable for 
> conex at all, just like you said. Before the last IETF, we went through 
> the alternatives for performing conex markings on IPv6 datagrams. These 
> were the requirements we were working with
> 
> R1: The information needs to be visible to all interested nodes on the
>     path.
> R2: The information needs to be able to traverse nodes that do not 
>     understand the markings.
> R3: The presence of the marking mechanism should not significantly alter 
>     the processing of the packet.

   That's pretty much where we stand.

   Hop-by-hop is pretty-much ruled out. Destination-Options is _so_
confusing that we hestitate to mention it.

   To add to the confusion, our primary algorithm talks of piggy-backing
on the ECN bits, and the most serious proposal so far (developed for
IPv4-land) talks of sort-of-redefining one of the four values of ECN
to show what I'll call "congestion-predicted" and adding one additional
bit to make sure all cases are covered.

   (I don't think it would help at this stage to go into more detail
of that proposal: there clearly are other ways we could cover-the-cases,
and actually it's premature to say we wouldn't want more than one-bit
precision on "congestion-predicted" -- however that proposal _does_
seem adequate for useful experiments. We are, after all, chartered to
produce an Experimental spec.)

> There were no real suitable mechanisms for IPv6 that met these 
> requirements other than using some free bits in the header. We would 
> greatly appreciate any hints you can provide us in this regard.

   It's early enough in the ConEx process that we're open to some quite
fundamentally different approaches. For example, we have discussed how
to expose congestion (along the path, at the IP layer) in cases where
ECN isn't deployed. We're exploring the possible -- and not really
expecting to like what we find. ;^)

--
John Leslie <john@jlc.net>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]