Subject: [edu-team] Remember "Networking 101"?

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 11 Nov 2004 00:00:30 -0500

Just FYI, I'm having an absolutely embarrassing conversation in SIP 
that just about proves that at least one party in the discussion 
doesn't understand either TCP or congestion avoidance, and I don't 
think that someone is me.

Now that we have more than 12 weeks till the next IETF, can we think 
seriously about this class? I can give you a list of mandatory 
attendees, and if I can't, I bet Jon Peterson can!

Spencer

From: "Spencer Dawkins" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, November 10, 2004 4:24 PM
Subject: Re: [Sip] PING/PONG

> Call me old-fashioned, but I'm requesting a point of clarification 
> about PING/PONG.
>
> As I should have said in the working group session when we discussed 
> this, I have no interest in chatting about UDP versus TCP. If you 
> choose UDP, I assume you did it for a reason, and the discussion at 
> the working group session makes sense to me.
>
> Having said that,
>
>> With UDP, the PING will create a new NAT binding and the server can 
>> update
>> its mapping for the UA.
>>
>> With TCP, if you want to be able to detect that the NAT binding is 
>> gone on
>> the order of a transaction timeout, you would need to send a PING 
>> every 32
>> seconds or so. Given that NAT bindings for TCP live longer than 
>> that, I
>> don't see what the CRLF buys you.
>
> it seems to me that if you have chosen to use TCP for some reason, 
> you need to at least consider living with TCP behavior on retries.
>
> The TCP protocol is extremely persistent, uses exponential backoff 
> (typically to a maximum of 60-64 seconds per retry), and in most 
> vanilla implementations will not declare a connection unusable for 
> something like 10-15 minutes.
>
> If a path is lost, for any reason, TCP will use this behavior (the 
> behavior that allows the Internet to survive the World Wide Web 
> today).
>
> If you are using TCP and you don't like this behavior, and you don't 
> get a response back when you wanted to get a response back, the 
> application choices are:
>
> - sit on your hands and wait for the TCP connection to fail,
>
> - close the TCP connection and open another one, or
>
> - close the TCP connection, sit on your hands for some period of 
> time, and open another one.
>
> The second choice (immediate retry) requires that you reset the TCP 
> connection (one packet), send a SYN to open a second TCP connection 
> (one packet), and potentially ACK an incoming SYN/ACK (one packet), 
> and then resend your application message (could be piggybacked but 
> most TCP stacks will use a separate packet).
>
> Immediately sending up to four new packets when you detect loss of 
> one packet, with the possibility that the single-packet loss is due 
> to network congestion, seems too aggressive.
>
> Sitting on your hands and letting TCP retry doesn't seem much worse 
> than sitting on your hands and then setting up a new TCP connection.
>
> Are we assuming that network congestion is not an issue any more?
>
> Thanks for any guidance you can provide!
>
> Spencer 

_______________________________________________
edu-team mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/edu-team

---

From: Radia Perlman <[email-masked]>
Date: Thu, 11 Nov 2004 10:45:05 -0800

An overview of networking in 1 1/2 hours can't cover everything. It 
should demystify
stuff like an IGP vs BGP and TCP vs UDP and IPv4 vs IPv6 and DNS and
XML. Other topics like QOS, telephony, TCP congestion avoidance behavior,
etc., I think should have separate more focused tutorials. It's possible 
these sorts of
things can be lightly covered, but not in the kind of depth that I think 
would make
Spencer happy (from the email he just sent).

A few of us sat down and thought of some potential overview classes. 
Examples are:
a) overview of networking (and my view of it would be such that it 
wouldn't include
an overview of how IETF is organized, or naming all the WGs, or details of
some of the things above). It could include things like scalability 
(examples of
protocols with exponential overhead, e.g.,) configurability (need to 
manage a running
network one node at a time), forward compatibility (specifying behavior 
based on
version number), which are things to think about when designing any 
protocol.
This class I'd be enthusiastic about doing.

b) telephony and IP (SIP, MEGACO, ...). I think Scot Bradner would be a good
person to do this, but I'm sure he could suggest others.

c) management, MIBs, etc.: I talked to Bert who is enthusiastic about 
working with
a non-management person to make it really tutorial, though he also 
believes in
letting someone who doesn't already have the AD limelight give the 
tutorial, and
he mentioned several names of potential people to me

d) bridging/routing/switching: overview of that, plus difference between 
BGP and
IGPs, ARP vs ND, link state vs distance vector, policies, QOS: This I 
could do
at any time, and there are a lot of people in IETF that need to 
understand this
better (even though IETF doesn't do bridging, it's important to 
understand implications
of things like duplicating layer 2 addresses within a bridged LAN).

I'd like to propose if we want to start cycling away from the security 
one, that I
do this one next time, since it's all prepared and would probably be 
widely useful

e) congestion/QOS

f) other topics?