Re: [alto] Proposal for ALTO re-charter

["Martin Stiemerling" <[e-mail]>]

Hi,

 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> wangaijun
> Sent: Wednesday, June 23, 2010 9:56 AM
> To: [e-mail]; 'Enrico Marocco'; [e-mail];
> 'Richard Alimi'
> Cc: [e-mail]; [e-mail]; 'Likai'
> Subject: [alto] Proposal for ALTO re-charter
> 
> Hi,Vijay,Enrico,Jon and Alimi
> 
> 
> 
> From previous discussion, we can know the Server Notification
> Mechanism(SNM) is important for the communication efficiency between
> ALTO Server and ALTO Client. It is very similar to the "Traffic

I particular cannot recognize the importance of this mechanism, this is still not clear even after the last discussions and slides I've seen in the past.

One technical question: 
The SSM would required to keep the TCP connection between the ALTO client and ALTO server up and running at all times, even if there is no request from the  ALTO client and no to be delivered responsed from the server. This open TCP is required to let the server send this SSM to the client at any time. 

Have you considered if this system scales well compared to the HTTP approach of the ALTO protocol were you have open TCP connections only for the time of performing the request/response. 

> Guidance System",in which the traffic control department will broadcast
> the real traffic information actively to guide the car to avoid the
> congested road, or notify the driver that some area are in "traffic
> control", in order to assure the performance of some high priority
> traffic.

This comparison isn't doing right:
car traffic guidance systems typically work on a broadcast basis, as you have described, but the SSM would be unicast mechanism. So what's the comparison here?

> 
> 
> 
> Considering this, we propose to modify the current ALTO charter to
> reflect this requirement and add it into the final ALTO output. For
> example:

I'm opposing this change, as there is in my opinion no real use case behind this. Second this is overloading the ALTO protocol with a functionality beyond the originally envisioned functionality. 

With best regards

  Martin

> 
> 
> 
> A.  In ALTO charter, we can add the new section as below:
> 
> The WG will focus on the following items:
> 
> 1.  A "problem statement"......(omitted)
> 
> 2.  A requirement document......(omitted)
> 
> 3.  A request/response protocol......(omitted)
> 
> 4.  (New part)A document to define the server notification
> mechanism(SNM) in order to make the communication between ALTO Server
> and ALTO Client more efficient, let the traffic keep up with the change
> of network topology and more optimized. It should include the detailed
> description of SNM, its main aim, the notification mode, message
> format/processing procedure and implementation guidance. The
> relationship with query/response protocol should also be considered.
> 
> 5.  ......(omitted)
> 
> 
> 
> B.  In draft-ietf-alto-reqs-04.txt, add the subsection:
> 
> 3.1 ALTO Client Protocol(Original part)
> 
> ......
> 
> 3.2 ALTO Server discovery(Original part)
> 
> ......
> 
> 3.3 ALTO Server Notification(Added part, detailed content will be added
> later)
>     REQ. ARV04-46 ...
> 
> REQ. ARV04-47 ...
> 
>     ......
> 
> 3.4  Security and privacy(Original part)
> 
> ......
> 
> 
> 
> Is it feasible for above thoughts? If OK, we will provide the detailed
> proposal and the updated draft about "server notification mechanism ".
> 
> 
> 
> Best Regards.
> 
> 
> 
> 
> 
> Wang Aijun
> 
> Network Infrastructure Research Division
> 
> Network and Service Research Department
> 
> China Telecom Coporation Beijing Research Institute
> 
> 
[e-mail]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014