Re: [re-ECN] Preferential Dropping

[John Leslie <[e-mail]>]

McCann Peter-A001034 <[e-mail]> wrote:
> John Leslie wrote:
>> 
>> I'm not sure whether preferential dropping belongs in ConEx at all.
>> It seems like an ECN thing to me.
> 
> My understanding of the re-ECN proposal is that any congested
> link, anywhere along the path, should drop negative or neutral
> packets before dropping any re-ECN marked packets.  This seems
> to require some sort of "re-ECN support" on even backbone routers.

   It's not _my_ understanding that any such support on backbone
routers is expected, least of all "required"

   Perhaps Bob or Matt could correct me if I misunderstand...

>> The issue is whether anything about ConEx markings could signal a
>> trustworthy assurance that ECN marking is more likely to result in
>> earlier backoff.  
>> 
>> This doesn't feel particularly in-charter to me (at least not in
>> the initial charter); but we have until Thursday at least to discuss
>> things that are _not_ in-charter.  
> 
> Well, this question might be a factor in deciding whether to pursue
> a per-packet marking or an out-of-band signaling (OAM) type solution.

   While I can agree that an Out-of-Band mechanism would be easier
to "secure" and thus perhaps be more "trustworthy" for securing
preferential dropping, that's really quite a different problem than
ConEx set out to solve.

   Furthermore, it doesn't seem sufficiently "scalable" to me. How
would we manage a Key-Distribution-System to all the routers that
may need to decide whether to preferentially-drop certain packets?

> If only the first and last hop ISPs need to understand ConEx to
> implement the ingress policing and the egress dropping, then there
> seems to be some hope that out-of-band signaling might work.

   Indeed, there is "some hope" it could work. But the scalability
and key-distribution issues make me very hesitant to pursue it.
(If nothing else, keeping flow-state synchronized between ends feels
pretty daunting to me.)

> On the other hand, if the backbone routers need to see the ConEx
> markings, then they would either need to keep per-flow state in
> the out-of-band signaling case or there would need to be some node
> aggregating the signaling, similar to what has been tried for RSVP
> deployments.  It could be a mess.

   I am willing to discuss such issues, either before or after
chartering. But I think it most unwise to have a charter that
requires us to design an out-of-band system.

--
John Leslie <[e-mail]>