Subject: [arch-d] Mobility Responsibilities

From: John Leslie <[email-masked]>
Date: Thu, 4 Jan 2007 16:56:59 -0500

Pekka Nikander <[email-masked]> wrote:
> To: John Leslie <[email-masked]>
> 
>> Regardless, I'd be really surprised if _nobody_ has a wishlist
>> concerning mobility, security, and/or privacy. It would be really
>> helpful if we gathered these wishlists within the next week...
> 
> A. Mobility functionality we may need on almost all "layers":
> 
> 1. physical layer looks like the best layer for handling local, fast,  
> radio based mobility (MIMO etc)
> 
> 2. link layer looks like the best layer for handling local, cross  
> link or cross base station mobility

   Let's not worry about the division between these two layers.

> 3-4. internetworking and/or transport looks like the natural layer  
> for global host mobility; there are weak indications (signalling  
> efficiency, aggregation etc) indicating that internetworking is  
> probably better

   I'll get back to this...

> 5. personally, I still don't understand all the subtleties related to  
> session mobility, especially inter-node session handovers, and e2e  
> error correction and congestion control state

   Nor do I... But I suggest trying to pack most congestion managment
into the Transport layer.

> 7. if we had proper application naming aggregation structures, we  
> could most probably handle subnet mobility and application-level  
> delegation much better than today

  It doesn't seem helpful to me to treat application mobility as the
same animal -- It seems more like load-sharing than mobility, and it
doesn't seem to require coordination between server and client ends. 

Getting back to Internetting / Transport:

   Global Host Mobility means to me:

- nodes (much like laptops) will change their physical location;
- there will be periods when no bidirectional path is working;
- we cannot always know what network they will connect to next;
- we can assume one end (or a midpoint) has stable connectivity;

   I would guess we want:

- endpoints to find each other within a few round-trip times;
- sessions to continue after a break and reconnect;
- details of the topology change invisible to applications;

   Are these statements correct? Are they complete?

   Responsibilities I see for Internetworking layer are:

- loop-free routes should be found to any reachable locator;
- it should be possible to signal congestion to the sender;
- it should be possible to "punish" senders that don't throttle
  the traffic sent when congestion is signaled;

   Pekka seems to want an additional responsibility:

- an alternate path should be found when one path fails.

   I tend to disagree, because:

- ideally, the congestion level which equals failure should be
  configured at a higher level (not constant for all sessions);
- both the old and the new paths would need to be loop-free; 
- I'm not sure congestion signalling can be kept straight;

   So I tentatively assign that to the Transport layer...

   Responsibilities I see for Transport layer are:

- the rate of sending should be reduced if congestion is seen;
- the other end should be notified of alternate locators;
- dropped packets should be detected and retransmitted;
- at some congestion level an alternate locator should be tried;
- duplicate packets should be detected and eliminated;
- traffic should migrate to the least congested locator;

   How does this look?

--
John Leslie <[email-masked]>

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: John Leslie <[email-masked]>
Date: Thu, 4 Jan 2007 17:14:40 -0500

Pekka Nikander <[email-masked]> wrote:
> 
> B. Different security functions we will need on almost all "layers":
> 
> 1. physical layer is a great place to implement geographic location  
> security and over-the-air opportunistic encryption, etc.

   I don't see what good this info will do there...

> 2. link layer is a good place to include network access control

   I didn't envision any changes here.

> 3-4. there are indications that the location of IPsec, i.e., between  
> traditional internetworking and traditional transport, is a good  
> choice for placing e2e encryption and integrity

   I tend to agree; but I don't feel able to state your intent as
desires and responsibilities.

> 7. it is cumbersome to place user and service authentication and  
> access control outside of the application layer, as they have their  
> application specific aspects

   There is, however, a tendency to rely on lower-level info. I'm not
sure whether this calls for any new responsibilities...

> C. It is impossible to properly implement privacy without considering  
> all "layers" simultaneously
> 
> 1-7. just consider session tracking and mobility

   I was expecting some desires re: difficulty to backtrack from ULID
to personal info. We could in principle make this arbitrarily hard...