Subject: [alto] IETF74 - Current status and agenda requests

From: Enrico Marocco <[email-masked]>
Date: Wed, 18 Feb 2009 21:31:02 +0100

Folks,

As you can see on the DRAFT agenda for the SF meeting, the ALTO working
group is going to meet in a 2-hour session on Thu March 26 (expect the
day to change!). Since the first deadlines are approaching fast, the
chairs would like to make the best use of meeting time to make progress
toward meeting them. Such deadlines concern the following documents:

+ problem statement: this is the milestone with higher priority (WGLC is
  supposed to start in April 09). The WG has not adopted a draft yet,
  but draft-marocco-alto-problem-statement is the strong candidate which
  has accompanied the charter in the WG creation process and which Eric
  and Jan have volunteered to take over from the original authors,
  integrating the comments received during the previous meetings and
  getting it into a much better shape. If you haven't read the latest
  version yet, please do so before the meeting, comment and help improve
  it further; or, if you really think you can't live with it, the
  meeting in SF will be probably your last chance to present an
  alternative;

+ requirements: draft-kiesel-alto-reqs was discussed during the last two
  meetings, but it seems there is still no fundamental agreement in the
  WG about the approach the requirements document should adopt. The
  situation has now been stale since Minneapolis: if you want to
  contribute to this work and have an opinion, this is the very right
  time to let the group hear it;

+ ALTO protocol: the time constraints are a bit more relaxed than for
  other documents, but here is where all the fun is! Some proposals have
  already been presented in Minneapolis and we plan to assign time to
  updates and to the more to come. People willing to contribute may do
  so reviewing and commenting on the various proposals, helping with the
  editing of existing documents (feel free to contact the authors, ask
  the chairs if unsure), or submitting their own drafts. (Advice from
  very personal experience: in case you decide to submit your
  contribution, look at the proposals already on the table and focus
  your effort on the pieces of a possible solution you are most
  interested in, explaining very well all the whys and the hows, rather
  than trying to specify THE protocol.)

Vijay, Jon and I are supposed to submit the preliminary agenda by March
11; if you want a slot, please send us a request by then.

-- 
Ciao,
Enrico

---

From: "Howard, Lee" <[email-masked]>
Date: Fri, 20 Feb 2009 11:10:12 -0500

Thanks for framing specific areas for comment.

P Go Green! Print this email only when necessary. Thank you for helping Time Warner Cable be environmentally responsible.

-----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Enrico Marocco
> Sent: Wednesday, February 18, 2009 3:31 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [alto] IETF74 - Current status and agenda requests
> 
> Folks,
> 
> As you can see on the DRAFT agenda for the SF meeting, the ALTO
working group is
> going to meet in a 2-hour session on Thu March 26 (expect the day to
change!). Since the
> first deadlines are approaching fast, the chairs would like to make
the best use of meeting
> time to make progress toward meeting them. Such deadlines concern the
following
> documents:
> + problem statement:

I can live with it.  Some comments/questions:
The definition of resource is clunky.  "Content" is very different from
a "server process"
like a relay server.  I'd like to see these called out as separate but
equal definitions.

Figure 1 includes a "Super-peer (Tracker, proxy)".  None of those terms
is defined in the
Definitions section, or in the description of the figure.

Section 4.2 is useful, but I wonder if it could be more explicit that
ALTO is not expected
to help choose among anycast instances, or among caches not defined in
the ALTO 
service.  That is, if I download from a web site using HTTP or FTP, and
the site 
presents me with a list of servers, ALTO is not expected to help me
choose.

I'm having trouble visualizing the "ephemeral node" mentioned in 5.2,
but that may
be a lack of imagination on my part.

None of these is absolutely essential.

>   time to let the group hear it;

It's close, but I'm not sure yet.  I've missed previous discussions, so
please
forgive any retreads. . 

In the introduction, an example using ALTO "to select a media relay
needed for
NAT traversal" is given.  Great example, I want it, but I had to tilt
and squint
to see how NAT traversal could be content (it can't; it's definition #2
of
"resource".)

I think REQ#2 includes two separate requirements:
	An ALTO client MUST be able to query information from the ALTO
service.
	An ALTO server MUST provide guidance for selecting a resource
provider.

I need explicitness in REQ#4.  The way I read REQ#17, the server must
include
authorization; as an ISP, I could refuse to authorize third parties
access to ALTO
data, or limit their access differently than customer-clients.  I
probably want to do 
that, to prevent malicious discovery from any random ALTO queriant.  But
REQ#4 
seems to say I MUST support queries from not-my-customer, on behalf of
my 
customer, about what points are relatively close to my customer.   Maybe
it just 
says the *protocol* must support, and I can live with that, as long as
it's 
understood that any given *server* may not allow queries from external
resource 
directories.

I don't understand REQ#6.  Does it mean the ALTO protocol must use a 
congestion-aware transport, or does it mean whatever application makes
use of
ALTO guidance should use a congestion-aware protocol?  If the former,
it's unclear.
If the latter (i.e., 'BT should use congestion control'), that's a good
idea, but not a
requirement of the ALTO protocol.

In REQ#7 I would like to include that ALTO MUST work if an empty
response
is received.  In other words, the case where the ALTO server has no
clues to
offer.  For this and following REQs, we probably need a term, like "No
information
available" or "No guidance" or "Null response" or "Empty response."   

REQ#12 says that the required response to "I'm busy" is to act as if no
response
was received.  REQ#9 says the client may retransmit if not response is
received.
I suggest REQ#12 should say "as if it had received an empty reply, i.e.,
no
guidance."  

More later, but that's what I got from the two urgentish drafts.

Thanks,

Lee

This E-mail and any of its attachments may contain Time Warner
Cable proprietary information, which is privileged, confidential,
or subject to copyright belonging to Time Warner Cable. This E-mail
is intended solely for the use of the individual or entity to which
it is addressed. If you are not the intended recipient of this
E-mail, you are hereby notified that any dissemination,
distribution, copying, or action taken in relation to the contents
of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any
copy of this E-mail and any printout.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 20 Feb 2009 11:23:19 -0600

>> + requirements: draft-kiesel-alto-reqs was discussed during the 
>> last twomeetings, but it seems there is still no fundamental 
>> agreement in the WG about the approach the requirements document
>> should adopt. The situation has now been stale since Minneapolis:
>> if you want to contribute to this work and have an opinion, this is
>> the very right time to let the group hear it;
> 
> It's close, but I'm not sure yet.  I've missed previous discussions,
> so please forgive any retreads. .

This is a reminder to folks on this list that we have
assiduously archived the previous alto discussion (at 73rd
IETF).

For those who are looking to catch up on the discussions
on problem-statement and requirements (since these are
the two high-runners right now), please see the alto wiki
page (URL below) that has links to each individual audio
session, correspondent slideshow, and correspondent minutes.

The URL for the archives of the alto session at the 73rd IETF is:
http://tools.ietf.org/wg/alto/trac/wiki

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/