RE: Why do we have or should have keep-alive packets?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Gorry,

I think this is a nice taxonomy of keep-alive use cases.  The question,
I think, is what are the problems that arise when zero-length packets
are used for (all) keep-alives?  One of the problems appears to be
disambiguation.

For use 1 (NAT refresh), no one at the receiver cares about receiving
the packets.  For use 2 (connection state) DCCP will take action with
the received packets.  And for use 3 (application state) the application
needs to receive the packets.  When a zero-length packet is received,
how do you tell what its purpose is?

Do we need to reserve zero-length packets for use by only one of these
functions?

Tom P.

-----Original Message-----
From: Gorry Fairhurst [mailto:gorry@xxxxxxxxxxxxxx] 
Sent: Monday, March 26, 2007 7:09 AM
To: gorry@xxxxxxxxxxxxxx; dccp@xxxxxxxx
Subject:  Why do we have or should have keep-alive packets?


This email is to start a discussion on the use and requirements for
protocol
keep-alive packets in DCCP. This is a follow-up to discussing the
RTP/DCCP
draft.

A keep-alive packet is defined here as a packet that is sent when the
protocol has no data to send. Such packets provide no specific protocol
function, except to indicate that the protocol end points still have
protocol state.

The notes below capture some of the ideas inspired by the DCCP WG
meeting in
Prague. Please add more ideas and thoughts...

1. Uses of Keep-Alive at the Network Layer:
    a) To refresh network-layer soft state (e.g. NAT, Firewall pinholes)

2. Uses of Keep-Alive at the Transport Layer:
    a) To verify network path (rtt change, loss indication)
        - to modify congestion parameters.
    b) To verify remote reachability (end host transport still there?)
        - to terminate/reset connection.
    c) To verify transport state (application died? no loss?)
        - to retransmit or reset peer lost protocol state.

3. Uses of Keep-Alive at the Application Layer:
    a) To verify receiver state (socket open, application died?)
        - to terminate/reset connection.
    b) To verify network path (path changed?)
        - to modify flow-control/session parameters.

Do these lists have missing things, how clear is the suggested
separation in
functions between the two layers?

How often should we probe in this way?

Thoughts and comments are welcome!

Gorry


    






[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux