From yuri at ISI.EDU  Wed Aug  2 10:53:13 2006
From: yuri at ISI.EDU (Yuri Pradkin)
Date: Wed, 2 Aug 2006 10:53:13 -0700
Subject: [xcp] xcp in ns-2 update
Message-ID: <200608021053.13258@kmail.yap.isi.edu>

Hello,

Just a quick note on the status of xcp implementation in NS-2.

The upcoming NS-2 release (2.30) will include the following changes to 
XCP:

1. Change to XCP packet header to match NODIV-implementation for 
FreeBSD 6.0 from ISI, see 
	http://www.isi.edu/div7/isi-xcp/#software
for details.

2. Major change in XCP/TCP class hierarchy allowing for reduction in 
XCP/TCP code duplication and easier maintenance.  It also allows XCP 
to run over duplex TCP streams (FullTCP-subtree) so XCP can be used by 
traffic generators such as PackMime.

3. Minor updates to XCP test suites.


If you'd like to check out these features before the release (the date 
for the release has not been set, AFAIK), you can do it either by 
downloading a daily snapshot from ISI:
	http://www.isi.edu/nsnam/ns/ns-build.html
or via anonymous CVS:
	http://www.isi.edu/nsnam/ns/ns-anoncvs.html

SourceForge also has a browse-able ns-2 CVS at
	http://nsnam.cvs.sourceforge.net/nsnam/ns-2/
but these XCP changes were not limited to xcp-directory.

  -Yuri

From falk at ISI.EDU  Sun Aug  6 07:24:12 2006
From: falk at ISI.EDU (Aaron Falk)
Date: Sun, 6 Aug 2006 07:24:12 -0700
Subject: [xcp] Fwd: [Iccrg] Explicit feedback
References: <001601c6b92f$a2677b10$0200a8c0@fun>
Message-ID: <CBD3DFDB-6B55-4FE0-AD51-4C17F27DC1A8@isi.edu>

A message on the IRTF Congestion Control Research Group mailing list  
of possible interest to folks here...

--aaron

Begin forwarded message:

> From: Michael Welzl <michael.welzl at uibk.ac.at>
> Date: August 6, 2006 1:09:26 AM PDT
> To: iccrg <iccrg at cs.ucl.ac.uk>
> Subject: [Iccrg] Explicit feedback
>
> Hi,
>
> There is no doubt that explicit feedback from routers is useful
> for a congestion control mechanism - this has been illustrated
> by mechanisms like XCP and Quickstart (and several others).
>
> Yet, such mechanisms are critical because they require additional
> work in routers. So what is realistic? How much extra effort
> can one really assume from routers, when the scalability of
> a mechanism must not be constricted? And how should the
> provision of such feedback be specified - e.g. with pseudocode,
> as in the appendix of the XCP paper, or something else...?
>
> This kind of knowledge is missing in the congestion control
> landscape. Perhaps we can we make a change here.
>
> Presumably, the best answers would come from folks who
> work for router vendors - do we have some here? If so,
> could you please comment?
>
> Cheers,
> Michael
>
> _______________________________________________
> Iccrg mailing list
> Iccrg at cs.ucl.ac.uk
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg