Cannara | 1 Feb 2003 04:04

Re: [e2e] TCP Fragmentation

And, application/MAC configuration can easily affect this -- a local DOE lab
has servers thinking they're configured for FDDI, so sending 4kB PDUs down to
IP, which then does fragments.  Other protocols (AFS, NFS...) often simply
send Enet-sized IP PDUs as fragments.  Of course, fragmentation to smaller
MTUs than Enet should certainly not be around anymore -- ha, ha.

On the other side, setting the DF bit can be done with imaginary
FDDI/Token-Ring installs on Enet -- most Enet MACs can handle 4k frames (as
can bridges now), so efficiency goes up for transfers.

Alex

Janardhan Iyengar wrote:
> 
> John,
> 
> According to "Beyond Folklore: Observations on Fragmented Traffic" by
> Shannon, Moore and Claffy (from ToN, December 2002):
> 
> "While majority of the fragmented trafficis UDP [..], ICMP, IPSEC, TCP and
> tunneled traffic are commonly fragmented as well."
> 
> Although that doesn't answer your question per se, these results show that
> there are TCP stacks which allow fragmenting.
> 
> regards,
> jana
> 
> On Mon, 27 Jan 2003, John Border wrote:
> 
(Continue reading)

alok | 1 Feb 2003 13:32

Re: [e2e] TCP Fragmentation

Hello,

I think IP itself allows with DF bit and all that stuff in there..

so why do you mean by a TCP specific question?

....

are u specifically asking about "when i encap TCP stacks"?

----- Original Message -----
From: Janardhan Iyengar <iyengar <at> mail.eecis.udel.edu>
To: John Border <border <at> hns.com>
Cc: <end2end-interest <at> postel.org>; <dillon <at> hns.com>;
<gsbutakia <at> hss.hns.com>; <dbhattacharya <at> hss.hns.com>
Sent: Saturday, February 01, 2003 4:52 AM
Subject: Re: [e2e] TCP Fragmentation

> John,
>
> According to "Beyond Folklore: Observations on Fragmented Traffic" by
> Shannon, Moore and Claffy (from ToN, December 2002):
>
> "While majority of the fragmented trafficis UDP [..], ICMP, IPSEC, TCP and
> tunneled traffic are commonly fragmented as well."
>
> Although that doesn't answer your question per se, these results show that
> there are TCP stacks which allow fragmenting.
>
> regards,
(Continue reading)

john smith | 1 Feb 2003 14:53
Picon
Favicon

Re: [e2e] TCP Fragmentation

> Although that doesn't answer your question per se, these results show that
> there are TCP stacks which allow fragmenting.
>

Hello,

Fragmentation is built in the IP layer.

Are you proposing a "non IP Layer3 TCP" implementation?

Then TCP will not fragment the DF bit way...

Also, of you refer to MTU constraints and MSS as "fragmentation", then all
TCP stacks "frame" (call it fragment, framing).....?

All TCP stacks do that.

-JS

Picon
Favicon

Re: [e2e] wiretapping and charging

Washington Post article January 30:

 Feds Building Internet Monitoring Center

 National Communications System (NCS), a Defense agency established in 1962,
 ... first asked about the possibility of receiving live feeds from
 ISPs, with few restrictions on the amount or scope of data requested,
 according to several providers.

Jon Crowcroft | 2 Feb 2003 00:17
Picon
Picon
Favicon

Re: [e2e] wiretapping and charging

wrong model - 

I WANT the feds to record all my traffic- then i can stop doing backup - i bet if they
outsource the storage beusiness properly, they can get a better deal than me

oh, but i want to prove that the y have strong partitioning of data by insisting on
occasional (random) retrievals to check they have my data right.

of course, they can bill me for that, but i can ask GCHQ, MOSSAD, NSA, , etc etc
and see who does the cheapest service

i dont see why intelligence agencies shouldnt be subject to free market forces just like
the rest of us.

In missive <5.2.0.9.2.20030131153651.03977c70 <at> 127.0.0.1>, "David P. Reed" typed:

 >>Recording user traffic would seem to be bad citizenship, and also a source 
 >>of liability - if it got mishandled it could make the copier liable for 
 >>whatever damages are caused.
 >>
 >>It's hard to believe that billing requires access to contents.   Billing 
 >>should work even if end-to-end encrypted, one would think.
 >>
 >>Instead, one could require that the traffic be authenticated at the billing 
 >>point - perhaps by wrapping it in IPSEC up to that point.
 >>
 >>At 10:22 AM 1/31/2003 -0500, ram.gopal <at> nokia.com wrote:
 >>>Greetings,
 >>>
 >>>For billing and other similar application,  network element (eg., 
(Continue reading)

Jing Shen | 2 Feb 2003 05:12
Picon
Favicon

Re: [e2e] wiretapping and charging

to my understanding, wiretaping the network connection and record anything transferred is a requirement from ISP  who want to charge anything it want.

Network storage is value-added sevice provided by ISPs.

The problem is: how could we find a blanance point between service/charge and

the law.  Some government asks ISPs to block some sites absolutely, and ISPs

want to charge some content while ICPs charge realtime service. the possible

solution is filtering content,which is really difficult.

Jing Shen

 Jon Crowcroft <Jon.Crowcroft <at> cl.cam.ac.uk> wrote:

wrong model -

I WANT the feds to record all my traffic- then i can stop doing backup - i bet if they
outsource the storage beusiness properly, they can get a better deal than me

oh, but i want to prove that the y have strong partitioning of data by insisting on
occasional (random) retrievals to check they have my data right.

of course, they can bill me for that, but i can ask GCHQ, MOSSAD, NSA, , etc etc
and see who does the cheapest service

i dont see why intelligence agencies shouldnt be subject to free market forces just like
the rest of us.

In missive <5.2.0.9.2.20030131153651.03977c70 <at> 127.0.0.1>, "David P. Reed" typed:

>>Recording user traffic would seem to be bad citizenship, and also a source
>>of liability - if it got mishandled it could make the copier liable for
>>whatever damages are caused.
>>
>>It's hard to believe that billing requires access to contents. Billing
>>should work even if end-to-end encrypted, one would think.
>>
>>Instead, one could require that the traffic be authenticated at the billing
>>point - perhaps by wrapping it in IPSEC up to that point.
>>
>>At 10:22 AM 1/31/2003 -0500, ram.gopal <at> nokia.com wrote:
>>>Greetings,
>>>
>>>For billing and other similar application, network element (eg.,
>>>routers)may need to duplicate user traffic
>>>to such application. But this seems like wiretapping and may not be
>>>considered legal. Is there any technical
>>>solution for this?
>>>
>>>Thanks in advance.
>>>Regards
>>>Ramg
>>>
>>>
>>>
>>

cheers

jon


Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, ZheJiang Province 310027
P.R.China


Do You Yahoo!?
"雅虎节日大转盘惊喜不断 快乐节日好礼连连!"
Luigi Rizzo | 2 Feb 2003 18:30

Re: [e2e] Dummynet loss distributions

On Thu, Jan 30, 2003 at 12:24:07PM -0500, Janardhan Iyengar wrote:
> Hi all,
> 
> We wish to use distributions other than uniform for losses in our SCTP
> emulation experiments using Dummynet. We understand that Dummynet supports
> only uniform distribution losses. Is it possible for us to use other loss
> models, in particular, bursty losses in Dummynet?

there is no explicit userland command to support that, though
changing the loss distrubution only involves a one-line change
in netinet/ip_dummynet.c where instead of calling the default
random number generator you call your own:

    if ( fs->plr && random() < fs->plr )
        goto dropit ;           /* random pkt drop                      */

Now your generator can become complex and require the "fs"
pointer as an input parameter, used as a key in case you want to
implement non-memoryless loss generator. But that is another story.

This said, there are probably other ways to simulate losses in
a slightly more realistic ways, such as imposing a bandwidth limitation
on the flow, or pointing another flow to the same pipe.

	cheers
	luigi
----------------------------------+-----------------------------------------
 Luigi RIZZO, luigi <at> iet.unipi.it  . ICSI (on leave from Univ. di Pisa)
 http://www.iet.unipi.it/~luigi/  . 1947 Center St, Berkeley CA 94704
 Phone: (510) 666 2988
----------------------------------+-----------------------------------------

Poh Tze Ven | 3 Feb 2003 18:03
Picon
Favicon

[e2e] IP Table Size

Hi,

I need some information from ISPs (more ISPs the better) regarding active
network elements (in particular, routers) that capable of routing IP packets in
their networks. The information is needed only for statistical purpose. The
following are what I seek for:

(i)  The average size of IP forwarding table (in term of number of IP prefixes)
excluding AS border routers.

(ii) The average number of external prefixes in the forwarding table (exclude AS
border routers).

(iii) The average number of external prefixes in forwarding table of an AS
border router.

(iv) Rough estimation of number of routers in the domain.

Please reply directly to my e-mail address.

Thank you in advance.

Tilman Wolf | 6 Feb 2003 22:27
Picon

[e2e] Call for Participation: OPENARCH 2003

[Our apologies if you receive multiple copies of this e-mail.]

          C A L L   F O R   P A R T I C I P A T I O N

                      IEEE OPENARCH 2003
        6th International Conference on Open Architectures
                   and Network Programming

                       April 4-5, 2003
                      San Francisco, CA
                 Co-located with INFOCOM 2003
                   http://www.openarch.org

You are invited to join us at IEEE OPENARCH 2003, the 6th
International Conference on Open Architectures and Network
Programming. This annual conference provides an international
forum on open programmable networks, open signaling and control,
distributed systems technologies, active networks, and their
applications.

The program of OPENARCH 2003 features:
* Presentations on cutting-edge research from academic and
   industrial speakers,
* A keynote by David L. Tennenhouse (VP Corporate Technology
   Group, and Director of Research, Intel Corporation),
* A panel discussion "Programmability, Active Networking,
   Applications and the OpenArch Community" with Randy Katz
   (UC Berkeley) and Raj Yavatkar (Intel Labs),
* A panel discussion "Packets Everywhere? Views on IP
   infrastructure evolution from Active Networking to Circuit
   Switching" with Nick McKeown (Stanford), Jonathan Smith
   (UPenn), and Hui Zhang (CMU and Turin Networks).

For the complete program, please visit:
http://www.openarch.org/program.html

Registration is easy and can be done as part of your INFOCOM
registration:
http://www.ieee-infocom.org/2003/registration.htm
EARLY REGISTRATION available until February 28, 2003.

Hotel info available at:
http://www.ieee-infocom.org/2003/hotel_reservation.htm

For general information please check the conference web site.

Klaus Wehrle | 3 Feb 2003 20:11
Picon
Favicon

[e2e] CFP: IWQoS 2003 - Dealine approaching - Feb. 14, 2003


                *CALL FOR PAPERS*

         ELEVENTH INTERNATIONAL WORKSHOP
          on QUALITY of SERVICE (IWQoS)

         http://iwqos03.cs.berkeley.edu/

                June 2-4, 2003
               Doubletree Hotel
             Monterey, California

Supported by technical co-sponsorship by/in-cooperation with
IEEE Communications Society, ACM SIGCOMM and ACM SIGMOBILE
(approval pending).

Important dates:
----------------
Paper deadline:             *February 14, 2003*
Notification of acceptance: March 24, 2003
Final paper due:            April 8, 2003

IWQoS is a successful series of workshops providing an international
forum for the presentation and discussion of new research and ideas on
quality of service (QoS). The goal of the workshop is to bring
together researchers, developers, and practitioners working in this
area to discuss recent and innovative results, and identify future
directions and challenges, in developing practical systems where
predictable and controlled performance is a central requirement.

Papers are solicited on all aspects of architecture, algorithm, and
protocol design for systems in which QoS requirements are important.
In addition to traditional IWQoS topics such as service guarantees and
admission control, papers offering research contributions related to
robustness, resilience, security, and predictability in networking and
distributed systems are particularly solicited.

Topics of interest include, but are not limited to:

* Scalable QoS architectures
* Analytical and simulation models for QoS
* QoS control for middleware
* QoS-aware programming models and languages
* QoS issues in overlay and peer-to-peer networks
* QoS issues in ad-hoc networks
* Robust and resilient systems
* Content delivery networks with service guarantees
* Service assurances in wireless and mobile environments
* QoS support for information appliances
* Modeling user and application QoS requirements
* Charging, accounting, and pricing for QoS
* Experiences with QoS (measurements, tests, evaluations)

IWQoS aims to allow rapid dissemination of research results and to
provide fast turnaround. The deadline for papers is therefore as close
to the conference as the publishers allow. In the past the workshop
has been cross-disciplinary, well focused, with the emphasis on
innovation. As a result, a considerable amount of time is devoted to
informal discussion.

Submission instructions are available at:
http://iwqos03.cs.berkeley.edu/

Co-Chairs:
----------
Kevin Jeffay, University of North Carolina
Ion Stoica, University of California at Berkeley

Publicity Chair:
---------------
Klaus Wehrle, ICSI/ICIR Berkeley

IWQoS Steering Committee:
-------------------------
Thomas Gross, ETH Zurich
Jorg Liebeherr, University of Virginia
David Hutchison, Lancaster University
Peter Steenkiste, CMU
Ralf Steinmetz, Darmstadt University of Technology
Lars Wolf, University of Braunschweig
Hui Zhang, CMU and Turin Networks

Program committee:
---------------------------------
Nina Bhatti, University of Arizona
Andrew T.Campbell, Columbia University
Anna Charny, Cisco Systems
John Chuang, University of California, Berkeley
Rene Cruz, University of California, San Diego
Constantinos Dovrolis, Georgia Tech
Anja Feldmann, Technical University Munich
Victor Firoiu, Nortel Networks
Thomas Gross, ETH Zurich
David Hutchison, Lancaster University
Shiv Kalyanaraman, Rensselaer Polytech Institute, NY
Dina Katabi, MIT
Jasleen Kaur, University of North Carolina
Srinivasan Keshav, Ensim
Edward Knightly, Rice University
Jorg Liebeherr, University of Virginia
Jane Liu, Microsoft
Nick McKeown, Stanford University
Marco Mellia, Politecnico di Torino
Klara Nahrstedt, University of Illinois
Abhay Parekh, ICSI/ICIR Berkeley
Balaji Prabhakar, Stanford University
Raj Rajkumar, CMU
Peter Steenkiste, CMU
Harrick Vin, University of Texas
Klaus Wehrle, ICSI/ICIR Berkeley
John Wroclawski, MIT
Hui Zhang, CMU
Zhi-Li Zhang, University of Minnesota

Further General Information
===========================
http://iwqos03.cs.berkeley.edu/

--

-- 
  Klaus Wehrle
  International Computer Science Institute (ICSI)
  1947 Center Street, Berkeley, CA, 94704-1198, USA
  http://www.icsi.berkeley.edu/~wehrle


Gmane